This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Hi all, I've now locally fixed most whitespace issues and will upload them if I have the login data. I have fixed some other small bugs, and I did my best to avoid new bugs. Below you find some other issues I came across (I could have directly fixed some of them, but I felt it was better to let you know): [1] examples-364-2.xq I mentioned this one before (bug #6665). This query will only yield true if <p> is defined as paragraph delimiter. So it might be helpful if the comparison mode was set to "Inspect" - or if <p> could somewhat be defined as default delimiter in the test suite. [2] FTAnd-badexpr1.xq An exception (XPTY0004) is thrown here as the FTWordsValue is an empty expression - but I didn't find a hint why this is not allowed. Could you give me some hints? [3] ftstemming-q5.xq I would only expect one book as result (the first one), as the second book does not contain a stemmed "improve" term. [4] FTOrder-andor1.xq The query uses the following ftcontains expression: ...[/books/book/para ftcontains("swift" ftand "persuasion") ftor ("ninja" ftand "software") ordered]... One <para> element contains all four terms. As "swift" and "persuasion" appear in the correct order, I wouldd intuitively assume a match here. Instead, the propsed result is empty. But maybe I got this one wrong.. [5] FTDistance-complexwords4.xq, FTDistance-complexexpr2.xq, FTDistance-complexexpr1.xq, FTDistance-complexexpr3.xq The current results accept the term "Usability Studies", which is actually excluded by the query. The correct result probably is <title>Software For Fun and Profit, 2nd edition</title> [6] FTDistance-complexwords5.xq I'm not sure: can "window 0 words", which is used here, yield any results at all? I would expect "2" as minimum. Next, is the distance here 2 or 3 words? [7] FTScope-q3.xq, FTScope-q4.xq See [1]; <p> is implicitly assumed as paragraph delimiter. [8] FTNot-q1.xq, FTContent-q2.xq, FTNot-unconstrained-q1.xq As <para> does not occur in all the <book> elements, the results of the three queries should each contain only four <title> elements. [9] full-text-composability-queries-results-q5.xq The "if/then/else" expression is parsed and output as part of the text node: ...if (count($book/metadata/author) > 0) ... [10] xquery-xpath-composability-queries-results-q9.xq I get the expected result if the count(..) function is rewritten a little: old: count(./part/chapter) * 3 new: count($cont/part/chapter) * 4 [11] ftmatchoptions-q1.xq, ftlanguage-q2.xq Alternative error "FTST0009" missing. [12] Extension3.xq Parsing issue; the second option must be prefixed by "option": ...option ex:option2... [13] FTWindow-sentences1.xq, FTWindow-sentences3.xq, FTWindow-paragraphs1.xq, FTWindow-paragraphs3.xq, FTWindow-complexwords3.xq Parsing issue: "exactly " obsolete. [14] FTWindow-paragraphs1.xq See [1].. <p> is expected to delimit paragraphs. [15] ftstopword-q4.xq - ftstopword-q9.xq "StopWordList1.xml" does not exist ("StopWordList.xml" ?) [16] ftstopword-q4.xq, ftstopword-q7.xq, ftstopword-q8.xq "union" -> "union at" / "except" -> "except at" [17] ftstopword-q7.xq "FTST0008" expected, as StopWordList3.xml is missing. [18] ftstopword-q9.xq Parsing issue; superfluous "(" [19] ForScoreExpr-2.xq, ForScoreExpr-4.xq "as xs:string" should be removed (XPTY0004, type mismatch). [20] FTContent-complex2.xq "50..." FTUnit missing (probably "words"). [21] FTSelection-Weight-q1f.xq, FTSelection-Weight-q1g.xq, FTSelection-Weight-q1h.xq "as xs:double" should be removed (XPTY0004, type mismatch). [22] FTIgnore-q2.xq Alternative error "FTST0007" missing. I hope/guess that most XQFTTS bugs will be fixed after this has been discussed. Best, Christian
Hi Christian, I have some responses for you. [3] ftstemming-q5.xq I would only expect one book as result (the first one), as the second book does not contain a stemmed "improve" term. --Yes. I have removed the Bk 2 from the results. [9] full-text-composability-queries-results-q5.xq The "if/then/else" expression is parsed and output as part of the text node: ...if (count($book/metadata/author) > 0) ... --Corrected. Here is the new return statement: return <book number="{$book/@number}"> {$title if (count($book/metadata/author) > 0) then ($book/metadata/author, $in, $pin) else ($book/metadata/publicationInfo/publisher, $in, $pin) } </book> --Will also fix in use cases. [10] xquery-xpath-composability-queries-results-q9.xq I get the expected result if the count(..) function is rewritten a little: old: count(./part/chapter) * 3 new: count($cont/part/chapter) * 4 --The Full Text Task Force discussed the ./part/chapter and decided that it was acceptable syntax. I corrected the 3 to 4. --Will also fix in use cases. [11] ftmatchoptions-q1.xq, ftlanguage-q2.xq Alternative error "FTST0009" missing. --Added, also to ftlanguage-q1.xq [15] ftstopword-q4.xq - ftstopword-q9.xq "StopWordList1.xml" does not exist ("StopWordList.xml" ?) --Fixed to "StopWordList.xml" Also in ftstopword-q5.xq and ftstopword-q6.xq and ftstopword-q7.xq and ftstopword-q8.xq [16] ftstopword-q4.xq, ftstopword-q7.xq, ftstopword-q8.xq "union" -> "union at" / "except" -> "except at" --Fixed as proposed. Also in ftstopword-q9.xq [17] ftstopword-q7.xq "FTST0008" expected, as StopWordList3.xml is missing. --Fixed the query to call the right stop word lista 1,2,4,5. Also ftstopword-q9.xq [18] ftstopword-q9.xq Parsing issue; superfluous "(" --I removed the ()s. I agree they weren't necessary. Pat
Dear Pat, some quick comments to [9] and [10].. [9] full-text-composability-queries-results-q5.xq My parser still seems to complain about the new version; the following return statement might do its job: ---------------------- return <book number="{$book/@number}">{ ($title, if (count($book/metadata/author) > 0) then ($book/metadata/author, $in, $pin) else ($book/metadata/publicationInfo/publisher, $in, $pin)) }</book> ---------------------- This an equivalent version, which is a little bit shorter: return <book number="{$book/@number}">{ ($title, if ($book/metadata/author) then $book/metadata/author else $book/metadata/publicationInfo/publisher, $in, $pin) }</book> ---------------------- [10] xquery-xpath-composability-queries-results-q9.xq Sorry, I didn't write too much on this. "./part/chapter" is grammatically correct, but no context item is defined at this point, leading to an XPDY0002 error. This is why I suggested to replace "." with "$cont". Thanks! Christian
Christian, [9] full-text-composability-queries-results-q5.xq My parser still seems to complain about the new version; the following return statement might do its job: return <book number="{$book/@number}">{ ($title, if (count($book/metadata/author) > 0) then ($book/metadata/author, $in, $pin) else ($book/metadata/publicationInfo/publisher, $in, $pin)) }</book> --I added the comma after $title and the parens you suggested. Done in test suite and use cases. [10] xquery-xpath-composability-queries-results-q9.xq Sorry, I didn't write too much on this. "./part/chapter" is grammatically correct, but no context item is defined at this point, leading to an XPDY0002 error. This is why I suggested to replace "." with "$cont". --Mary assisted me with these and she recommended I change the period to $cont and I have so done. Part of her explanation is: "The use of the term "context item" suggests that we do bind the context item to the search context item, in which case the "." would be OK. On the other hand, we don't come out and say so explicitly..." Pat
(In reply to comment #0) > > [12] Extension3.xq > > Parsing issue; the second option must be prefixed by "option": > > ...option ex:option2... Fixed. > [13] FTWindow-sentences1.xq, FTWindow-sentences3.xq, > FTWindow-paragraphs1.xq, FTWindow-paragraphs3.xq, > FTWindow-complexwords3.xq > > Parsing issue: "exactly " obsolete. Fixed. (For FTWindow-paragraphs3.xq, it was "at least", not "exactly".) > [20] FTContent-complex2.xq > > "50..." FTUnit missing (probably "words"). Fixed.
On items #1, #7, and #14 we decided to change the instructions to make clear that we use <p> as a paragraph (and ipso facto sentence) delimiter, particularly in those cases derived from examples in the document, which follows this rule. The instructions also provide instructions on what implementations can do should they follow different rules. On item #2, #4, #5 we agree and will fix. #6 the query should use "window 2 words" #8 was already fixed, but not checked in.
On #19-22 agreed, done. I believe this resolves everything.
..last comments: [8] FTContent-q2.xq Result file "FTContent-q2.xml" contains <result> element, which is not specified by the query [19] ForScoreExpr-4.xq "as xs:string" should be removed (XPTY0004, type mismatch); comments in query files (ForScoreExpr-2 and -4) and XML catalog still talk about the "as" clause.
It appears that this comment has been fully resolved, but no response was made to Comment 7, even though the corrections have long since been made. This comment does not change the status of the bug (RESOLVED/FIXED), but merely acknowledges the final corrections. If you are satisfied with the changes, please mark this bug CLOSED.