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 10857 - [XQuery11] Use of 'URILiteral':NCName as name in element/attribute construction underspecified
Summary: [XQuery11] Use of 'URILiteral':NCName as name in element/attribute constructi...
Status: RESOLVED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XQuery 3.0 (show other bugs)
Version: Working drafts
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Jonathan Robie
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-09-30 14:40 UTC by Henry Zongaro
Modified: 2011-04-26 19:06 UTC (History)
2 users (show)

See Also:

Attachments

Description Henry Zongaro 2010-09-30 14:40:12 UTC 
Consider the following expression:

   element 'http://example.org':elem { }

In section 3.8.3.1 of the XQuery 1.1 internal last call draft, the second paragraph describes how the constructed node name is determined "If the keyword element is followed by a lexical QName," and the third paragraph describes how the constructed node name is determined "If the keyword element is followed by a name expression."  According to section 2, "A lexical QName is a name that conforms to the syntax of [http://www.w3.org/TR/REC-xml-names/#NT-QName]."

The name in this example is specified using neither a lexical QName nor a name expression.  I suspect it was intended that the name here should be treated in the same way as a name expression that yields a value of type xs:QName with no prefix.  If that was the intent, the draft should be revised to state that.


Now consider the following expression:

   attribute 'http://example.org':attr { }

Section 3.8.3.2 again describes how the constructed node name is determined "If the keyword attribute is followed by a lexical QName," and how the name is determined "If the keyword attribute is followed by a name expression."  So again the name in this example is described by neither paragraph.

In the case of a name expression, item 2.a in the list that follows states, "If the expanded QName returned by the atomized name expression has a namespace URI but has no prefix, it is given an implementation-dependent prefix."  Presumably attribute names specified using an EQName that consists of a URI Literal followed by a colon and NCName should be treated in the same way.
Comment 1 Jonathan Robie 2010-11-16 17:52:35 UTC 
The Working Group agrees. I will make these changes.
Comment 2 Henry Zongaro 2011-01-06 15:25:33 UTC 
The modified text in section 3.8.3.2 still doesn't address how the prefix of the attribute that results from evaluating a computed attribute constructor such as the following is determined.

  attribute 'http://example.org':attr { }

The second paragraph of 3.8.3.2 states, in part, "if the EQName has a URILiteral it is expanded using the specified URI....  The resulting expanded QName (including its prefix) is used as the node-name property of the constructed attribute node."  But that doesn't say how the prefix is determined.

Compare this with item 2.a in the list that describes how an expanded QName that results from evaluating a name expression is handled.

I would suggest changing the clause in the second paragraph that reads "if the EQName has a URILiteral it is expanded using the specified URI" to "if the EQName has a URILiteral it is expanded using the specified URI as the a namespace URI, an implementation-dependent prefix, and the specified NCName as the local name."  (The existing text didn't say what to do with the NCName in that EQName.)
Comment 3 Michael Kay 2011-01-07 23:10:50 UTC 
I would achieve the same effect as comment #2 but in a slightly different way.

I don't think that the rules for expanding an EQName into a (prefix, uri, local) triple should depend on the context where the EQName appears. I think "uri":local should always expand to a QName in which the prefix is absent, regardless where it occurs.

The rules for attribute constructors should then be refactored to recognize that the absent prefix can arise both in the existing scenario of "attribute {$q}" and also in the new scenario of "attribute 'uri':local"; in both cases an implementation-defined prefix is allocated.
Comment 4 Henry Zongaro 2011-01-08 11:30:16 UTC 
I agree with the proposal in comment #3.  The text in section 2 of the latest working draft of XQuery 3.0 describes how a lexical QName is expanded into an expanded QName, but doesn't describe how an EQName that has a URILiteral should be expanded.
Comment 5 Jonathan Robie 2011-04-11 22:09:53 UTC 
I also agree with Comment #3. This requires a Working Group decision.
Comment 6 Jonathan Robie 2011-04-26 19:06:04 UTC 
(In reply to comment #5)
> I also agree with Comment #3. This requires a Working Group decision.

We determined that this is purely editorial. I will make this change.