[xq31] computed element and attribute constructors: can the name expression return "Q{uri}local"?

[michaelhkay]

In the specification for element {expr} {content} and attribute {expr} {content}, it is stated that "If the atomized value of the name expression is of type xs:string or xs:untypedAtomic, that value is converted to an expanded QName." But it is not stated how that conversion is done. In particular, it is not stated whether it is acceptable for the expression to evaluate to a string in the format "Q{uri}local". It is clear that names in this format can be supplied statically, but it is unclear whether they can be supplied dynamically.

[michaelhkay]

The fact that the text goes on to say "If the string value contains no namespace prefix, it is treated as a local name in the default element/type namespace. " strongly suggests that the WG simply overlooked this possibility. Nevertheless, it was clearly the WG's intent to allow uri-qualified names to be used in all contexts that lexical QNames are allowed, except where conformance to XML syntax dictates otherwise.

For direct element constructors, the grammar clearly allows a name in the form Q{uri}local, but again, the rules do not say exactly how this should be interpreted. The text in §3.9.1 starting "If the element name in a direct element constructor has a namespace prefix,..." clearly overlooks the fact that the grammar has been extended. I think we have to generate a no-prefix name, which will result in a default namespace declaration.

[michaelhkay]

Also worth noting: in XSLT, xsl:element is explicit that a "Q{uri}local" name is NOT allowed. This too is probably an oversight, but in this case there is no inconsistency in the spec: it is quite categorical "The name attribute is interpreted as an attribute value template, whose effective value must be a lexical QName."

[ChristianGruen]

Some thoughts on this:

1. As far as I can recollect, the URI string of an expanded QName needs to be whitespace-normalized before it is interpreted and accepted as namespace URI. I think this should also happen with dynamically supplied URI strings.
2. XQDY0074 may be the appropriate error code if http://www.w3.org/2000/xmlns/ is supplied as URI string.
3. Do we want to interpret entities at runtime, or will certain URIs not be available dynamically?

Element constructor	Result	Dynamic construction with escaped entities (if supported)
element Q{&#x7b;}a {}	<a xmlns="{"/>	element { 'Q{&#x26;x#7b;}a' } {}
element Q{&amp;}a {}	<a xmlns="&amp;"/>	element { 'Q{&amp;amp;}a' } {}

[michaelhkay]

Interpreting entities at run-time would be unprecedented and seems a really bad idea. XQuery only recognises entity references in literals because it's trying to mimic XML syntax as closely as possible.

As regards XSLT, I now think that disallowing a braced URILiteral in xsl:element and xsl:attribute is probably intended and wise, because it would interact in a non-obvious way with the namespace attribute of those instructions.

I think it's probably the case that the only current usage of a dynamic BracedURILiteral in XQuery is in the 3rd argument of format-number, where it's defined by reference to the XPath (not XQuery) rules. These rules do invoke whitespace normalization (though XSD says that whitespace in URIs is "highly discouraged" and we have syntax in which it simply won't work, eg. xsi:schemaLocation). Perhaps, given that the rules aren't obvious, it's a mistake to interpret them as being allowed; but then, in the static case the syntax clearly allows them but the semantics are under-specified, so we have to consider that case too...