[Bug 1286] Qname type in XQueryX and Schema

http://www.w3.org/Bugs/Public/show_bug.cgi?id=1286





------- Additional Comments From davidc@nag.co.uk  2005-05-11 23:09 -------
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>

Received on Wednesday, 11 May 2005 23:09:51 UTC