(In reply to Tim Mills from comment #0)
> 
> 1. Incorrect conversion of \uXXXX.  e.g. re00741 where the string literal
> 
> '[^a-f-[\x00-\x60\u007B-\uFFFF]]+'
> 
> becomes
> 
> <xqx:stringConstantExpr>
> <xqx:value>[^a-f-[\x00-\x60{-&#65535;]]+</xqx:value>
> </xqx:stringConstantExpr>

I think this is the same problem as in Bug 13796.

(In reply to Tim Mills from comment #0)

> 2.  More XML 1.1 problems.  e.g. line-ending-Q006, where
>                <xqx:stringConstantExpr>
>                  <xqx:value> &#8232; </xqx:value>
>                </xqx:stringConstantExpr>
> 
> isn't the same as ' &#x2028; '.

Looks the same to me. What's the problem?

> 
> 3. Incorrect conversion of element(name, type?) (e.g. fn-nilled-40) 
> missing <xqx:nillable />

That definitely looks like a bug.

> 4. Incorrect conversion of eqname-009.
> 
> Q{ http://www.example.com/ ns }b
> 
> is converted to
> 
>     <xqx:nameTest xqx:URI=" http://www.example.com/ ns ">b</xqx:nameTest>

I'm pretty sure that's a valid conversion, because it back-converts to exactly the original URIQualifiedName.


> but should probably be
> 
>     <xqx:nameTest xqx:URI="http://www.example.com/ ns">b</xqx:nameTest>

I believe that too would be a valid conversion, because it back-converts to a URIQualifiedName that, although lexically different from the original, is semantically the same.

Does the Working Group have a preference?

(In reply to Michael Dyck from comment #2)
> (In reply to Tim Mills from comment #0)
> 
> > 2.  More XML 1.1 problems.  e.g. line-ending-Q006, where
> >                <xqx:stringConstantExpr>
> >                  <xqx:value> &#8232; </xqx:value>
> >                </xqx:stringConstantExpr>
> > 
> > isn't the same as ' &#x2028; '.
> 
> Looks the same to me. What's the problem?

&#x2028; is LINE SEPARATOR.

This test is for a processor which follows the XML 1.1 line ending rules.  Such a processor will perform line ending normalization on &#x2028;.

When converted to XQueryX/XML 1.0 the &x2028; is not treated by the XML parser as a line ending character.  It would be if it were XQuery/XML 1.1.

(In reply to Michael Dyck from comment #4)
> > 4. Incorrect conversion of eqname-009.
> > 
> > Q{ http://www.example.com/ ns }b
> > 
> > is converted to
> > 
> >     <xqx:nameTest xqx:URI=" http://www.example.com/ ns ">b</xqx:nameTest>
> 
> I'm pretty sure that's a valid conversion, because it back-converts to
> exactly the original URIQualifiedName.
> 
> 
> > but should probably be
> > 
> >     <xqx:nameTest xqx:URI="http://www.example.com/ ns">b</xqx:nameTest>
> 
> I believe that too would be a valid conversion, because it back-converts to
> a URIQualifiedName that, although lexically different from the original, is
> semantically the same.
> 
> Does the Working Group have a preference?

True.  As an aside, I note that xqx:URI is an xs:string, and wonder why it's not an anyURI.   

 I'll change our XQueryX processor to perform the normalization.

(In reply to Tim Mills from comment #5)
> (In reply to Michael Dyck from comment #2)
> > (In reply to Tim Mills from comment #0)
> > 
> > > 2.  More XML 1.1 problems.  e.g. line-ending-Q006, where
> > >                <xqx:stringConstantExpr>
> > >                  <xqx:value> &#8232; </xqx:value>
> > >                </xqx:stringConstantExpr>
> > > 
> > > isn't the same as ' &#x2028; '.
> > 
> > Looks the same to me. What's the problem?
> 
> &#x2028; is LINE SEPARATOR.
> 
> This test is for a processor which follows the XML 1.1 line ending rules. 
> Such a processor will perform line ending normalization on &#x2028;.
>
> When converted to XQueryX/XML 1.0 the &x2028; is not treated by the XML
> parser as a line ending character.  It would be if it were XQuery/XML 1.1.

Ah, right, the conversion-to-XQueryX code only ever generates files with
    <?xml version="1.0"?>
I suppose it could generate version="1.1" for test-cases that have
    <dependency type="xml-version" value="1.1"/>
but is that enough? Could there be an XQueryX processor that only accepts 1.1 files, and so would (also) want a "1.1" version of the vast majority of test-cases that don't have an xml-version dependency?

Or is an XQueryX processor obliged to handle input in *all* versions of XML? The XQueryX spec doesn't seem to say explicitly, but it says:
    An XQueryX processor that claims to conform to this
    specification MUST implement the XQueryX syntax as defined in
    4 'An XML Schema for the XQuery XML Syntax' of this specification ...
and an XML document conforms to that syntax regardless of its version decl, right? So if "implementing the syntax" means "recognizing all instances of the syntax", that suggests that a conforming XQueryX processor must accept input in all versions of XML.

(In reply to Tim Mills from comment #5)
> 
> When converted to XQueryX/XML 1.0 the &x2028; is not treated by the XML
> parser as a line ending character.  It would be if it were XQuery/XML 1.1.

On second thought, I'm not so sure. Semantically, an XQueryX processor evaluates a query by:
(a) transforming it to the human-readable syntax; and
(b) evaluating the human-readable syntax.
And it's not clear that the version of XML used in (a) must match the choice of choice of rules for normalizing line breaks in (b).

Specifically, although the query begins with
    <?xml version="1.0"?>
and so must be processed by an XML 1.0 processor, which will leave the Line Separator as is, that happens at (a), and it's still possible for the XQuery processor at (b) to use the end-of-line rules of XML 1.1 (as indicated in the test-case), which *will* normalize the Line Separator into a Line Feed.

(Or it can skip the test-case if it's unable to use the 1.1 rules at (b).)

(In reply to Michael Dyck from comment #3)
> > 
> > 3. Incorrect conversion of element(name, type?) (e.g. fn-nilled-40) 
> > missing <xqx:nillable />
> 
> That definitely looks like a bug.

I believe I've now fixed that bug in the converter.
This adds <xqx:nillable/> to its output for the following tests:
    fn-nilled-40
    fn-nilled-42
    fn-nilled-43
    fn-nilled-49
    fn-nilled-53
    hof-039
    hof-053
    K2-ExternalVariablesWith-22
    K2-ExternalVariablesWith-22a
    K2-ExternalVariablesWith-23

I believe this bug is now fixed.