K2-SeqIntersect-42 also has a missing empty(...) function call wrapping the test in the XQueryX version

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.

Additional whitespace characters have also been introduced in K2-DirectConElemAttr-75

version_declaration-10 is another case that should be removed since it expects XQST0087

(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.

(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.

(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.

(In reply to comment #3)
> Additional whitespace characters have also been introduced in
> K2-DirectConElemAttr-75

As above, more information please.

(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.

fn-doc-33 and K2-OrderbyExprWithout-13 are still missing stable order-bys.

(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>

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.

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.

(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>

(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

(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.

We think that all the XQueryX tests now work, so I'll close this report.

I think this bug has reappeared - presumably when someone recreated the XQueryX tests.

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.

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

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

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.

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

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.

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.

(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".

(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.

(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.

> 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.

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.

All fixed, except for K2-DirectConElemAttr-75 (XQueryX only).

Michael, please change the substitution mode of K2-DirectConElemAttr-75.xq for me.

Done.

I've generated a new version of K2-DirectConElemAttr-75.xqx.

Confirmed fixed - thanks.