This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Consider the query <a xmlns="a-strange-uri{1,2}"/> I think this is legal, and it places element a in the namespace "a-strange-uri{1,2}". Now consider the query <a xmlns="a-strange-uri{1,-}"/> I think this is not legal, on the curious grounds that '1,-' is not a valid XPath expression. Although the text in 3.4.1.2 says "The value of a namespace declaration attribute must be a URILiteral;" (where one has to assume that "value" means the thing after the = sign including the delimiting quotes), the grammar treats the value as a DirAttributeValue. So we must assume that it must be both a URILiteral and a DirAttributeValue, and this requires that anything between curly braces is a valid XPath expression, even though it will never be evaluated as an XPath expression. This can give rise to some surprising error messages. To make matters even worse, it seems that the prefix actually being declared is in-scope within all these spurious XPath expressions, thus: <a xmlns:b="zzz{a:xyz}" xmlns:a="zzz{b:xyz}"/> is legal only because the prefixes used within the curly braces are both in scope. Although it's not nice to change the grammar at this stage of the game, I feel the only clean solution is to remove the requirement that the value of a namespace declaration attribute should be a DirAttributeValue. The grammar would thus become something like: DirAttributeList ::= (Attribute | Namespace)* Attribute ::= S QName S? "=" S? DirAttributeValue /* where QName is suitably restricted */ Namespace ::= S QName S? "=" S? UriLiteral /* where QName is suitably restricted */
A number of tests in the test suite adopt the interpretation that curly braces in the namespace URI are not allowed. For example, Constr-Namespace-25 is <elem xmlns="http://www.example.com{'/namespace'}"/> and expects XQST0022. I don't think this interpretation is justified by a literal reading of the spec: in this example the value is both a valid DirAttributeValue and a valid URILiteral. We could adopt this interpretation but the effect would be to outlaw namespace URIs containing curly braces, with no escape mechanism available. Although such namespace URIs are rare, they are legal, so this seems inadvisable. Another possible solution would be to recognize doubled curly braces as an escape representation of a curly brace. Other tests impacted are: K2-DirectConElemNamespace 15 to 18, 34 to 38, 44
For what it's worth, we interpretted this as: Namespace ::= ('"' (PredefinedEntityRef | CharRef | EscapeQuot | '{{' | '}}' | [^{}"&])* '"') | ("'" (PredefinedEntityRef | CharRef | EscapeApos | '{{' | '}}' | [^{}'&])* "'") and found the specification to be unhelpful here too.
The WG decided in principle that the URI should not be allowed to contain an unescaped curly brace, and that doubled curly braces should be interpreted as a single brace. MHK was actioned to proposed text to implement this decision (which involves no grammar change).
In response to action ACTION A-343-5, I propose the following changes: (1) In 3.7.1.1, list item 1, change the first sentence from <old>Each consecutive sequence of literal characters in the attribute content is treated as a string containing those characters.</old> to <new>Each consecutive sequence of literal characters in the attribute content is treated as a string containing those characters, except that any occurrence of "{{" is replaced by "{", any occurrence of "}}" is replaced by "}", and any occurrence of EscapeQuot or EscapeApos is replaced by a quotation mark or apostrophe character as appropriate.</new> (This seems to be an omission from the current rules for processing attribute values) (2) In 3.7.1.2 para 2, delete the sentence "The value of a namespace declaration attribute must be a URILiteral; otherwise a static error is raised [err:XQST0022]." (3) At the start of the bulleted list in 3.7.1.2, add the list item: * The value of the namespace declaration attribute (a DirAttributeValue) is processed as follows. If the DirAttributeValue contains an EnclosedExpr, a static error is raised [err@XQST0022]. Otherwise, it is processed as described in rule 1 of section 3.7.1.1 Attributes. An implementation MAY raise a static error [err:XQST0046] if the resulting value is of nonzero length and is not in the lexical space of xs:anyURI. The resulting value is used as the namespace URI in the following rules. (4) In the existing first bullet, change "The local part of the attribute name is interpreted as a namespace prefix and the value of the attribute is interpreted as a namespace URI. This prefix and URI..." to read "If the prefix of the attribute name is xmlns, then the local part of the attribute name is interpreted as a namespace prefix. This prefix and the namespace URI..." (5) In the existing second bullet, change "If the name of the namespace declaration attribute is xmlns with no prefix, the value of the attribute is interpreted as a namespace URI. This URI specifies ..." to "If the name of the namespace declaration attribute is xmlns with no prefix, then the namespace URI specifies ..."
On 23 Oct 2007 the WG agreed to accept the proposal in comment #2
In comment #5, "comment #2" should read "comment #4"
See Comments #4, #5, and #6.