W3C home > Mailing lists > Public > public-qt-comments@w3.org > May 2005

[Bug 1286] New: Qname type in XQueryX and Schema

From: <bugzilla@wiggum.w3.org>
Date: Tue, 03 May 2005 09:58:20 +0000
To: public-qt-comments@w3.org
Cc:
Message-Id: <E1DSuAW-0007xh-Pe@wiggum.w3.org>

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

           Summary: Qname type in XQueryX and Schema
           Product: XPath / XQuery / XSLT
           Version: Last Call drafts
          Platform: PC
        OS/Version: Windows 2000
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XQueryX
        AssignedTo: jim.melton@acm.org
        ReportedBy: davidc@nag.co.uk
         QAContact: public-qt-comments@w3.org


The schema declares many constructs to be of type QName, eg the first being

 <xsd:complexType name="varRef">
    <xsd:complexContent>
      <xsd:extension base="expr">
        <xsd:sequence>
          <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.

David
Received on Tuesday, 3 May 2005 09:58:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:05 UTC