5871 2008-07-17 13:46:43 +0000 CVS: wrong corresponding XQueryX tests 2010-04-20 11:59:22 +0000 1 1 1 Unclassified XML Query Test Suite XML Query Test Suite unspecified PC Windows NT CLOSED FIXED P2 normal --- 1 tim andrew.eisenberg jim.melton jmdyck nick oliver public-qt-comments oldest_to_newest 21212 0 tim 2008-07-17 13:46:43 +0000 I think some of the conversions of queries to XQueryX are wrong. Additional whitespace characters have been introduced in: K2-Literals-28 K2-Literals-39 K2-DirectConOther-50 K2-DirectConOther-54 K2-DirectConOther-68 K2-DirectConOther-69 K2-DirectConOther-70 The 'stable' specifiers on the "order by" clause are missing in: K2-OrderbyExprWithout-13 version_declaration-003 version_declaration-004 prolog-version-6 prolog-version-7 XMark-Q19 XMark-All There was a recent change to K2-SeqExprCast-422 which has not been reflected in the XQueryX conversion. Error XQST0087 cannot be raised by XQueryX, so the following XQueryX queries should be removed: K-VersionProlog-3 K-VersionProlog-4 21215 1 nick 2008-07-17 15:44:47 +0000 K2-SeqIntersect-42 also has a missing empty(...) function call wrapping the test in the XQueryX version 21216 2 oliver 2008-07-17 16:16:01 +0000 fn-doc-33 is another test missing the "stable" order specifier extvardeclwithtype-23 is missing some whitespace at the end of the css style element. 21234 3 oliver 2008-07-18 15:26:31 +0000 Additional whitespace characters have also been introduced in K2-DirectConElemAttr-75 21235 4 oliver 2008-07-18 15:32:20 +0000 version_declaration-10 is another case that should be removed since it expects XQST0087 21276 5 andrew.eisenberg 2008-07-22 15:19:55 +0000 (In reply to comment #0) > Additional whitespace characters have been introduced in: > > K2-Literals-28 > K2-Literals-39 > > K2-DirectConOther-50 > K2-DirectConOther-54 > K2-DirectConOther-68 > K2-DirectConOther-69 > K2-DirectConOther-70 Some of these XQueryX documents were updated on 2008/7/14 (in CVS, ... our XQTS zip file has not been updated in a while). Please take a look again and if you believe that they are still wrong, then please let me know what characters have been introduced and in what locations. > The 'stable' specifiers on the "order by" clause are missing in: > > K2-OrderbyExprWithout-13 > version_declaration-003 > version_declaration-004 > prolog-version-6 > prolog-version-7 > XMark-Q19 > XMark-All Agreed. These XQueryX documents have been updated. I'll republish our XQuery applet in the near future. > There was a recent change to K2-SeqExprCast-422 which has not been reflected in > the XQueryX conversion. K2-SeqExprCast-422.xqx was updated on 2008/7/14. Perhaps it contains the change that you refer to. > Error XQST0087 cannot be raised by XQueryX, so the following XQueryX queries > should be removed: > > K-VersionProlog-3 > K-VersionProlog-4 Agreed. These XQueryX documents have been removed. 21277 6 andrew.eisenberg 2008-07-22 15:21:31 +0000 (In reply to comment #1) > K2-SeqIntersect-42 also has a missing empty(...) function call wrapping the > test in the XQueryX version K2-SeqIntersect-42.xqx was updated on 2008/7/14.2008/7/14. I believe that it contains the missing function call. 21278 7 andrew.eisenberg 2008-07-22 15:24:31 +0000 (In reply to comment #2) > fn-doc-33 is another test missing the "stable" order specifier Agreed. These XQueryX documents have been updated. > extvardeclwithtype-23 is missing some whitespace at the end of the css style > element. Sorry, but I need more information on this missing whitespace. 21279 8 andrew.eisenberg 2008-07-22 15:25:25 +0000 (In reply to comment #3) > Additional whitespace characters have also been introduced in > K2-DirectConElemAttr-75 As above, more information please. 21280 9 andrew.eisenberg 2008-07-22 15:26:08 +0000 (In reply to comment #4) > version_declaration-10 is another case that should be removed since it expects > XQST0087 Agreed. This XQueryX document has been removed. 21281 10 oliver 2008-07-22 16:32:04 +0000 fn-doc-33 and K2-OrderbyExprWithout-13 are still missing stable order-bys. 21282 11 andrew.eisenberg 2008-07-22 22:14:54 +0000 (In reply to comment #10) > fn-doc-33 and K2-OrderbyExprWithout-13 are still missing stable order-bys. I have to disagree. Looking at fn-doc-33 in CVS, http://dev.w3.org/cvsweb/~checkout~/2006/xquery-test-suite/TestSuiteStagingArea/Queries/XQueryX/Functions/NodeSeqFunc/SeqDocFunc/fn-doc-33.xqx?rev=1.2&content-type=text/plain, I see the following: <xqx:orderByClause> <xqx:stable/> <xqx:orderBySpec> <xqx:orderByExpr> <xqx:functionCallExpr> <xqx:functionName>string</xqx:functionName> <xqx:arguments> <xqx:varRef> <xqx:name>i</xqx:name> </xqx:varRef> </xqx:arguments> </xqx:functionCallExpr> </xqx:orderByExpr> </xqx:orderBySpec> </xqx:orderByClause> Looking at K2-OrderbyExprWithout-13 in CVS, http://dev.w3.org/cvsweb/~checkout~/2006/xquery-test-suite/TestSuiteStagingArea/Queries/XQueryX/FLWORExpr/OrderbyExpr/OrderbyExprWithout/K2-OrderbyExprWithout-13.xqx?rev=1.2&content-type=text/plain, I see the following: <xqx:orderByClause> <xqx:stable/> <xqx:orderBySpec> <xqx:orderByExpr> <xqx:varRef> <xqx:name>b</xqx:name> </xqx:varRef> </xqx:orderByExpr> </xqx:orderBySpec> </xqx:orderByClause> 21283 12 andrew.eisenberg 2008-07-22 22:31:32 +0000 I've fixed the extraneous whitespace in the following XQueryX test cases: K2-DirectConElemAttr-75 K2-DirectConOther-50 K2-DirectConOther-53 K2-DirectConOther-54 K2-DirectConOther-68 K2-DirectConOther-69 K2-DirectConOther-70 I believe that I've fixed all of the test cases reported in comment #3, and all but the following test cases reported in comment #0: K2-Literals-28 K2-Literals-39 On these I still need more information. 21295 13 oliver 2008-07-23 10:23:10 +0000 Apologies with regard to fn-doc-33 and K2-OrderbyExprWithout-13 - they have been correctly fixed. With regards to extvardeclwithtype-23, the XQ version has this element constructor (on line 68): <style type="text/css"> .details {{ text-align: center; font-size: 80%; color: gray }} .variableName {{ font-family: courier }} </style> The equivalent part of the XQX version has this constructor: <xqx:elementConstructor> <xqx:tagName>style</xqx:tagName> <xqx:attributeList> <xqx:attributeConstructor> <xqx:attributeName>type</xqx:attributeName> <xqx:attributeValue>text/css</xqx:attributeValue> </xqx:attributeConstructor> </xqx:attributeList> <xqx:elementContent> <xqx:stringConstantExpr> <xqx:value> .details { text-align: center; font-size: 80%; color: gray } .variableName { font-family: courier }</xqx:value> </xqx:stringConstantExpr> </xqx:elementContent> </xqx:elementConstructor> which evaluates to: <style type="text/css"> .details { text-align: center; font-size: 80%; color: gray } .variableName { font-family: courier }</style> missing the newline and indentation at the end of the text node. K2Literals-28 and K2-Literals-39 seem fine to me. 21309 14 andrew.eisenberg 2008-07-23 22:12:05 +0000 (In reply to comment #13) > The equivalent part of the XQX version has this constructor: > > > <xqx:stringConstantExpr> > <xqx:value> > .details > { > text-align: center; > font-size: 80%; > color: gray > } > .variableName > { > font-family: courier > }</xqx:value> > </xqx:stringConstantExpr> I believe the XQueryX that has been generated is correctly reflecting an implicit value of strip for the Boundary-space policy static context property. The removal of the trailing whitespace is covered by section 3.7.1.4, Boundary Whitespace. The addition of "declare boundary-space preserve;" would generate <xqx:stringConstantExpr> <xqx:value> .details { text-align: center; font-size: 80%; color: gray } .variableName { font-family: courier } </xqx:value> </xqx:stringConstantExpr> 21310 15 davidc 2008-07-23 22:34:24 +0000 (In reply to comment #14) > I believe the XQueryX that has been generated is correctly reflecting an > implicit value of strip for the Boundary-space policy static context property. > The removal of the trailing whitespace is covered by section 3.7.1.4, Boundary > Whitespace. The final white space comes between }} and </style> }} is CommonContent not a DirectConstructor, or an EnclosedExpr, so I don't think that this is boundary whitespace, so should not be stripped irrespective of the setting of the boundary-space policy, David 21338 16 andrew.eisenberg 2008-07-25 17:53:37 +0000 (In reply to comment #15) > }} is CommonContent not a DirectConstructor, or an EnclosedExpr, so I don't > think that this is boundary whitespace, so should not be stripped irrespective > of the setting of the boundary-space policy, Quite so, David. Looking more closely, I found that the code generating the XQueryX was giving special consideration to {{ and not to }}. I've corrected this and posted a new version of extvardeclwithtype-23.xqx and extvardeclwithtype-23-static-cbcl.xqx. Tim, Nick, and Oliver, I believe that this addresses the last of the issues that you have raised. Please let me know if this is the case. 21356 17 tim 2008-07-28 15:29:55 +0000 We think that all the XQueryX tests now work, so I'll close this report. 31273 18 nick 2010-01-27 10:50:42 +0000 I think this bug has reappeared - presumably when someone recreated the XQueryX tests. 31293 19 andrew.eisenberg 2010-01-27 21:27:40 +0000 Looking quickly at this bug, it appears that there were several XQueryX bugs that I fixed. Please tell me which XQueryX test cases have reverted to their previous states and I'll get them fixed again. 31311 20 nick 2010-01-28 11:24:19 +0000 K2-DirectConOther-50 K2-DirectConOther-52 K2-DirectConOther-53 K2-DirectConOther-54 K2-DirectConOther-68 K2-DirectConOther-69 K2-DirectConOther-70 K-VersionProlog-3 K-VersionProlog-4 version_declaration-010 31405 21 andrew.eisenberg 2010-02-02 22:31:26 +0000 I've removed these XQueryX documents for these test cases (and ensured that they will not reappear): K-VersionProlog-3 K-VersionProlog-4 version_declaration-010 31407 22 andrew.eisenberg 2010-02-02 23:01:58 +0000 I'm struggling with the other test cases that you've identified. Let's look at K2-DirectConOther-50. The query is: string(<e><![CDATA[ ]]></e>) eq "&#xA;" Looking at it again, I see: string(<e><![ 73 74 72 69 6E 67 28 3C 65 3E 3C 21 5B CDATA[...]]></e> 43 44 41 54 41 5B 0D 0D 0A 5D 5D 3E 3C 2F 65 3E ) eq "&#xA;" 29 20 65 71 20 22 26 23 78 41 3B 22 The XQueryX that I generated for this test case was, in part: <xqx:value>< 3C 78 71 78 3A 76 61 6C 75 65 3E 3C ![CDATA[..]]></x 21 5B 43 44 41 54 41 5B 0A 0A 5D 5D 3E 3C 2F 78 qx:value>.. 71 78 3A 76 61 6C 75 65 3E 0D 0A 20 20 20 20 20 CVS seems to be changing this, but in a benign way. When I reload the current version, I see: <xqx:valu 3C 78 71 78 3A 76 61 6C 75 e><![CDATA[....] 65 3E 3C 21 5B 43 44 41 54 41 5B 0D 0A 0D 0A 5D ]></xqx:value>.. 5D 3E 3C 2F 78 71 78 3A 76 61 6C 75 65 3E 0D 0A The previous version of the XQueryX was: <xqx:valu 3C 78 71 78 3A 76 61 6C 75 e><![CDATA[..]]> 65 3E 3C 21 5B 43 44 41 54 41 5B 0D 0A 5D 5D 3E </xqx:value>.. 3C 2F 78 71 78 3A 76 61 6C 75 65 3E 0D 0A 20 20 I'm thinking that the current version (with or without the CVS change) reflects the rules in A.2.3 End-of-Line Handling. This interpretation would mean that the expected result of true is incorrect. 33571 23 tim 2010-03-15 10:31:29 +0000 Sorry for the delay in responding to this. The original query K2-DirectConOther-50.xq I see in CVS is: string(<e><![CDATA[ ]]></e>) eq "&#xA;" 0000600 6e69 2867 653c 3c3e 5b21 4443 5441 5b41 ing(<e><![CDATA[ 0000620 0a0d 5d5d 3c3e 652f 293e 6520 2071 2622 \r\n]]></e>) eq "& which contains only a single \r\n, equivalent to &xA;, not the two you show in Comment #22. In K2-DirectConOther-50.xqx I get from CVS 0001420 3e65 213c 435b 4144 4154 0d5b 0d0a 5d0a e><![CDATA[\r\n\r\n] 0001440 3e5d 2f3c 7178 3a78 6176 756c 3e65 0a0d ]></xqx:value>\r\n So the left hand string is \r\n\r\n which is equivalent to &xA;&xA;, but is being compared against a single &xA;. 0002260 2020 783c 7871 763a 6c61 6575 263e 7823 <xqx:value>&#x 0002300 3b41 2f3c 7178 3a78 6176 756c 3e65 0a0d A;</xqx:value>\r\n 33768 24 andrew.eisenberg 2010-03-22 20:07:24 +0000 So, we are seeing K2-DirectConOther-50.xq differently. You are seeing 0a 0d in the CDATA section, while I am seeing 0D 0D 0A. This seems like an OS and/or CVS issue. I'm using WinXP and WinCVS. Perhaps you could let me know what you are using. Looking further, I see 0D 0A in the CDATA section when I download the file directly from cvsweb. 33829 25 andrew.eisenberg 2010-03-23 23:04:28 +0000 I've replaced K2-DirectConOther-50.xq with K2-DirectConOther-50-binary.xq, checked it into CVS as a binary file and created a corresponding XQueryX file. The new file has 0D 0A in the CDATA section. Please let me know if you see the correct characters in the query and if the corresponding XQueryX is correct. If it is, then I will do the same thing for the other test cases that you have identified. 33837 26 jmdyck 2010-03-24 01:12:30 +0000 (In reply to comment #25) > I've replaced K2-DirectConOther-50.xq with K2-DirectConOther-50-binary.xq, > checked it into CVS as a binary file and created a corresponding XQueryX file. > The new file has 0D 0A in the CDATA section. > > ... I will do the same thing for the other test cases that you have identified. It would be easier to just change the substitution mode on the existing files, via "cvs admin -kb". 33905 27 tim 2010-03-25 10:02:09 +0000 (In reply to comment #24) I'm using Windows 7 with TortoiseCVS. I've updated from CVS and see files: K2-DirectConOther-50-binary.xq K2-DirectConOther-50.xq each of length 421 bytes. The files appear to be identical. I also see: K2-DirectConOther-50.xqx of length 1376 bytes. and K2-DirectConOther-50-binary.xqx of length 1374 bytes. I believe K2-DirectConOther-05-binary.xqx to be correct, and gives the result "true" when executed. 34442 28 andrew.eisenberg 2010-04-02 22:03:36 +0000 (In reply to comment #26) > It would be easier to just change the substitution mode on the existing files, > via "cvs admin -kb". I'm using WinCVS, and it will not allow me to change the substitution mode of files. Michael, I'd appreciate it if you would change the substituion mode and force a new version of these queries: K2-DirectConOther-50.xq K2-DirectConOther-52.xq K2-DirectConOther-53.xq K2-DirectConOther-54.xq K2-DirectConOther-68.xq K2-DirectConOther-69.xq K2-DirectConOther-70.xq I'll regenerate the XQueryX for them once you have done so. 34448 29 jmdyck 2010-04-02 23:01:40 +0000 > Michael, I'd appreciate it if you would change the substituion mode Done. > and force a new version Unnecessary, I think, but I did it to have somewhere to log the change in substitution mode and refer to this Bug. 34528 30 andrew.eisenberg 2010-04-05 02:15:44 +0000 Michael, thanks. I see new versions of these queries and have generated new XQueryX for them. Nick and Tim, I believe that the XQueryX for these test cases is now correct. I'm in an optimistic mood, and so will change the status to FIXED. I'll wait to see whether you close or reopen this bug. 34591 31 tim 2010-04-06 08:39:41 +0000 All fixed, except for K2-DirectConElemAttr-75 (XQueryX only). 34597 32 andrew.eisenberg 2010-04-06 13:07:35 +0000 Michael, please change the substitution mode of K2-DirectConElemAttr-75.xq for me. 34620 33 jmdyck 2010-04-06 21:47:43 +0000 Done. 35033 34 andrew.eisenberg 2010-04-14 20:30:09 +0000 I've generated a new version of K2-DirectConElemAttr-75.xqx. 35156 35 tim 2010-04-20 11:59:22 +0000 Confirmed fixed - thanks.