The XML Query Working Group considered this comment and has concluded that there
is not actually a technical error in the XQueryX specifications.  Instead, the
WG believes that the comment provides justification for an example that more
meaningfully demonstrates the use of namespaces in XQueryX, as well as one or
more informative Notes that remind the reader of the relationships of XQueryX
namespace usage and XQuery namespace usage. 

The editor was given authority to select a meaningful and useful example and add
it to the XQueryX spec. 

Please let us know if you agree with this resolution of your issue, by adding a
comment to the issue record and changing the Status of the issue to Closed. Or,
if you do not agree with this resolution, please add a comment explaining why.
If you wish to appeal the WG's decision to the Director, then also change the
Status of the record to Reopened. If you wish to record your dissent, but do not
wish to appeal the decision to the Director, then change the Status of the
record to Closed. If we do not hear from you in the next two weeks, we will
assume you agree with the WG decision.

I don't agree with this resolution.
It is very hard to come up with specific problems with the schema as
a) the mapping  from xquery to xqueryx is unspecified and 
b) The mapping from XqueryX to Xquery is via an XSLT1 stylesheet that doesn't
use the schema so in effect the schema could say anything at all and the
normative parts of the specification would be unaffected.

However this decision will make it very hard to work with XqueryX with any
schema-aware XML tools for example XQueryX or XSLT2.

Because the prefix (or lack of prefix) has meaning it will mean for example that
it will be possible to have two XqueryX files that are deep-equal according to
the Xquery/XPath core function library, but produce semantically different
Xquery expressions when processed with the normative XSLT1 stylesheet.

Apart from the problems with the default function namespace mentioned earlier
references to attribute names are similarly unsafe.

eg the document has
  <xqx:xpathAxis>attribute</xqx:xpathAxis>
                              <xqx:nameTest>year</xqx:nameTest>


so to a schema aware processor "year" here will be reported as a qname
representing local name year and namespace the default (element) namespace
and in particular it would be deep-equal (or in fact = or eq to a prefixed qname
representing the same namespace (although in this example document the default
element namespace is no-namepsace so the problem does not arise) 
when converted back to Xquery the prefixed and unprefixed QNames (even though
these are equal values in the XPath data model) produce
attribute::year or attribute::x:year 
and these refer to different attributes.
The problem goes away if nameTest is declared to be of type string with a facet
restricting its content to be a lexical QName.

http://www.w3.org/TR/2005/WD-xslt20-20050404/#schema-for-xslt

<xs:simpleType name="QName">
  <xs:annotation>
    <xs:documentation>
      A QName.
      This schema does not use the built-in type xs:QName, but rather defines
its own
      QName type. Although xs:QName would define the correct validation on these
attributes,
      a schema processor would expand unprefixed QNames incorrectly when
constructing the PSVI,
      because (as defined in XML Schema errata) an unprefixed xs:QName is
assumed to be in
      the default namespace, which is not the correct assumption for XSLT.
      The data type is defined as a restriction of the built-in type Name,
restricted
      so that it can only contain one colon which must not be the first or last
character.
    </xs:documentation>
  </xs:annotation>
  <xs:restriction base="xs:Name">
    <xs:pattern value="([^:]+:)?[^:]+"/>      
  </xs:restriction>        
</xs:simpleType>




 

The Working Group has (re)considered several comments related to handling to
QNames in XQueryX and plans to make changes to the XQueryX schema that will
handle QNames more effectively as your bug report requests. 

An additional comment will be posted here whenever the specific changes have
been made. 

Thanks for your ongoing interest in XQueryX. 

We believe that we have addressed your concerns in a new XQueryX schema that
defines the type of names to be a new xqx:QName type instead of the xs:QName
type used in the former schema.  Th xqx:QName type captures two strings, the
prefix and the local name, and has no dependencies of any sort on namespace
declarations in the XQueryX document (at the "XML level", that is).  The prefix
captured for a QName has only a relationship to namespace declarations at the
XQuery level (as represented in the XQueryX document, of course). 

We appreciate your feedback on the XML Query specifications. Please let us 
know if this response is satisfactory. If not, please respond to this 
message, explaining your concerns.

Jim Melton
On behalf of the XML Query Working Group

> Please let us know if this response is satisfactory.

Yes thanks. (I have W3C access and have seen a draft of the revised schema, I'm
sure that a schema along those lines would be more than enough to close all my
xqueryx comments)

David