This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 1286 - Qname type in XQueryX and Schema
Summary: Qname type in XQueryX and Schema
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XQueryX 1.0 (show other bugs)
Version: Last Call drafts
Hardware: PC Windows 2000
: P2 normal
Target Milestone: ---
Assignee: Jim Melton
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
Depends on:
Blocks: 1404
  Show dependency treegraph
Reported: 2005-05-03 09:58 UTC by David Carlisle
Modified: 2005-08-08 23:15 UTC (History)
0 users

See Also:


Description David Carlisle 2005-05-03 09:58:20 UTC
The schema declares many constructs to be of type QName, eg the first being

 <xsd:complexType name="varRef">
      <xsd:extension base="expr">
          <xsd:element name="name" type="xsd:QName"/>

The Qname attribute in Schema has the semantic that unprefixed names will be
reported as being in the default namespace for element names, this does not
match the semantic that you need here.

The examples in the document show almost no use of namespaces so the problems do
not show up very much in these examples. The only place that I noticed
is in the modelling of built in functions eg doc() which are modeled as the
QName representing local name doc and namespace URI "". THe Normative XSLT1
stylesheet masks this problem by ignoring the namespace and just taking the
local name which happens to work out as the right thing here, but in general
this will not work, and probably at least one of the exampels should be modified
to use namespaced elements or variable references for example.

For similar reasons the XSD styleshete for XSLT avoids the QName datatype and
just uses xsd:string, which can be constrained witha regexp facet to match the 
Name production without forcing QName type annotation.

Comment 1 Jim Melton 2005-05-11 19:38:04 UTC
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.
Comment 2 David Carlisle 2005-05-11 23:09:48 UTC
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

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.

<xs:simpleType name="QName">
      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
      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,
      so that it can only contain one colon which must not be the first or last
  <xs:restriction base="xs:Name">
    <xs:pattern value="([^:]+:)?[^:]+"/>      

Comment 3 Jim Melton 2005-06-02 20:50:07 UTC
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. 
Comment 4 Jim Melton 2005-06-27 20:06:20 UTC
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
Comment 5 David Carlisle 2005-06-28 13:01:24 UTC
> 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)