W3C home > Mailing lists > Public > public-qt-comments@w3.org > September 2010

[Bug 10727] New: [XQuery11] Problems with description on how to evaluate the prefix expression for constructed namespace nodes.

From: <bugzilla@jessica.w3.org>
Date: Fri, 24 Sep 2010 16:53:40 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-10727-523@http.www.w3.org/Bugs/Public/>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10727

           Summary: [XQuery11] Problems with description on how to
                    evaluate the prefix expression for constructed
                    namespace nodes.
           Product: XPath / XQuery / XSLT
           Version: Member-only Editors Drafts
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XQuery 1.1
        AssignedTo: jonathan.robie@redhat.com
        ReportedBy: oliver@cbcl.co.uk
         QAContact: public-qt-comments@w3.org


Section 3.8.3.7 says:

If the constructor specifies a PrefixExpr, the prefix expression is evaluated
as follows:

1. Atomization is applied to the result of the name expression.

2. If the result of atomization is a single atomic value of type xs:NCName,
xs:string, or xs:untypedAtomic, it is used as the prefix property of the newly
constructed namespace node. If the result is the empty sequence or an empty
string, the prefix property of the newly constructed namespace node is empty.
For any other result, a type error is raised [err:XPTY0004].

3.The URIExpr is evaluated, and the result is cast to xs:anyURI to create the
URI property for the newly created node.
An error [err:XQDY0101] is raised if the namespace URI in a computed namespace
constructor is bound to the predefined prefix xmlns, or if a namespace URI
other than http://www.w3.org/XML/1998/namespace is bound to the prefix xml, or
if the prefix xml is bound to a namespace URI other than
http://www.w3.org/XML/1998/namespace.


Several issues with this paragraph:

Step 1 refers to the name expression, and should refer to the prefix
expression.

Step 2 has the phrase "of type xs:NCName, xs:string, or xs:untypedAtomic".  In
this phrase xs:NCName is entirely redundant, as it is covered by xs:string.

Step 2 says nothing about what happens if the value is a string that isn't an
xs:NCName.  I guess it should say that the value should be cast to an
xs:NCName, and an appropriate error should be raised if this cast fails.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Friday, 24 September 2010 16:53:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:15:06 GMT