This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
For an XPath/XQuery release after 3.0, there is discussion about supporting maps, and one of the proposals is to support maps using a JSON-like syntax. For example a map constructor might take the form { "colour":white, "size":large, "weight":heavy } The current syntax for EQNames, for example "foo":bar, will create usability problems if we do this, as it will be necessary to use spaces around the colon for disambiguation. This bug report suggests that in the interests of keeping our options open, we should use a different syntax for EQNames. EQNames are intended primarily for use in software-generated code, and their readability is not of paramount importance. We should reconsider the original proposal to use a backtick (`foo`:bar) .
In today's telcon, there was a lot of sympathy for changing the syntax, but we have not yet agreed on a new syntax.
What about some kind of character followed by Clark notation? Norm and I discussed the possibility of "~" or "^", but landed upon "Q" which I think looks ok: Q{http:example.com}foo It should be parsed with ws:explicit - that is, as a single token (IMHO).
Q{http:example.com}foo +1 I like the continuity with Clark notation, which is well established
I'm slightly put off by the fact that {http://example.com} would play the role of a URILiteral without actually being one.
That's true, but URILiteral has no intrinsic meaning other than as a useful EBNF alias for StringLiteral - so it's probably not that big a deal.
(In reply to comment #4) > I'm slightly put off by the fact that > {http://example.com} > would play the role of a URILiteral without actually being one. I agree. We already have a way to delimit a URI literal, and it's well defined. There's a second shortcoming: Q{ } looks like it delimits the name, but it doesn't. I'd prefer something like: Q{"http://example.com/exemplia":local} Advantages: 1. URI Literal is recycled without change in meaning 2. : is recycled without change in meaning 3. The {} delimiters actually delimit the name
The main disadvantage being it's another unknown unfamiliar syntax, rather than actually reusing the de-facto standard for expressing expanded QNames.
(In reply to comment #7) > The main disadvantage being it's another unknown unfamiliar syntax, rather than > actually reusing the de-facto standard for expressing expanded QNames. As opposed to being *almost* the same as an existing syntax, and having two different ways to represent a URI literal in the same language ;-> Pure Clark notation won't parse in our grammar. We're going to have to modify it somehow. We may as well do it in a way that leverages the existing design of our language. I also think my proposed syntax is clear about whitespace handling. Anyone who knows XQuery knows what whitespace is in the URI for the following QName: Q{ "http://example.com/gratia":lpart } We can define the whitespace rules for the following syntax, but whatever definition we choose, it's one more thing to learn: Q{ http://example.com/gratia }lpart Should the above constant be allowed? If so, what whitespace does the URI contain?
I would favour John and Norm's proposal in comment 1... Q{http:example.com}foo
Thanks for discussing this issue; I would favor the Clark notation as well. Just to get sure: will the new proposed syntax be compatible with the existing syntax for computed constructors (e.g.: attribute Q{"text"} )?
Yes, the expanded QName syntax will be parsed with ws:explicit - ie: as a single token. This disambiguates it from existing syntax.
The joint working groups decided to resolve this bug by changing the EQName syntax to use the suggestion in comment #2.
The output of fn:path() also changes as a result of this decision. The changes have been made.