This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The current EQName production is: EQName ::= QName | URIQualifiedName URIQualifiedName ::= BracedURILiteral NCName /* ws: explicit */ BracedURILiteral ::= "Q" "{" [^{}]* "}" /* ws: explicit */ In a lengthy discussion [1] it turned out not to be very trivial to find out what happens if the URI inside the BracedURILiteral contains spaces. We say about this: "The namespace URI value is whitespace normalized according to the rules for the xs:anyURI type in Section 3.2.17 anyURI XS1-2 or Section 3.3.17 anyURI XS11-2" The types in XSD 1.0 and 1.1 have whitespace="collapse", which means that leading and trailing whitespace of the xs:anyURI value are removed. This makes the following equal: Q{http://www.w3.org/2005/xpath-functions/math }pi() Q{ http://www.w3.org/2005/xpath-functions/math }pi() Q{http://www.w3.org/2005/xpath-functions/math}pi() and the following indistinguishable: Q{http://foo bar}test Q{http://foo bar}test Currently, the first two above are rejected by Exselt and Saxon (as syntax error for not finding the function fn:pi()). However, the status-quo of the spec suggests this to be valid and equal (in Bug 29707 I requested some tests to this effect). Proposal: I don't think the spec is broken. I do think we ought to say something about this more explicitly than we do now (considering that two implementations seem to have got it wrong). Alternatively, disallow spaces in EQNames altogether, which will only disallow a very small corner use case (spaces in namespace URIs, which are strongly discouraged by the NS spec and cannot be used in quite a few applications). [1] https://lists.w3.org/Archives/Public/public-xsl-query/2016Jun/0068.html (and the mail thread before)
"I do think we ought to say something about this more explicitly than we do now" - We could have a note to say that the behaviour when namespace names contain spaces is implementation-dependentand move on with life. There's a good argument, however, for applying attribute value normalization, because that happens when xmlns and amlns:* "attributes" are encountered in XML instance documents. Either way makes sense to me. I don't see any reason to forbid spaces, and the longer we spend on obscure corner cases the slower we'll be to get to Rec!
I agree with Liam. The spec seems clear. If you're worried that implementations are getting it wrong for certain edge cases, the best way to tackle that is to submit some test cases.
I raised this because there was discussion on the subject that seemed to lean towards disallowing spaces. Since from the responses I understand that you agree the spec is clear (I had a different impression earlier), I'd follow-up on comment #2: I added such test cases in Bug 29707. If that suffices, I think this can further be closed with no action.
At the meeting on 2016-06-28, the WG discussed this under agenda item J4.3.4 DECISION: (bug 29708) no change to the production(s) or text of BracedURILiteral or EQName w.r.t. whitespace handling ACTION- A-648-01: in the Serialization XSD, fix the whitespace and make it MSXML4 compatible and fix any other issues that were raised in that thread (see https://lists.w3.org/Archives/Public/public-xsl-query/2016Jun/0078.html)
Thanks, closed now.