W3C home > Mailing lists > Public > public-qt-comments@w3.org > July 2009

[Bug 6131] [XPath 2.1] Requirement: context-free paths

From: <bugzilla@wiggum.w3.org>
Date: Thu, 09 Jul 2009 13:25:32 +0000
To: public-qt-comments@w3.org
Message-Id: <E1MOtcy-0001de-QB@wiggum.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6131





--- Comment #17 from John Snelson <john.snelson@oracle.com>  2009-07-09 13:25:32 ---
(In reply to comment #15)
> >XQuery SX doesn't have an expression that starts with "{" any more.
> 
> That's good. In that case the only problem I can see "by eye" is
> 
> [134] CompElemConstructor  ::= "element" (QName | ("{" Expr "}")) "{"
> ContentExpr? "}"
> 
> and the equivalent for attributes, where one would have to insist that the
> QName is a QName in the current sense, and not an EQName.

Either that or require that a Clark name has no spaces in it. If it's matched
as a single token then there's no ambiguity.

> If we go for Clark names, the other question is what do about namespace names
> containing "{" or "}". The simplest is just to say they aren't allowed when
> using this format. That's not a big restriction because the namespace spec
> strongly encourages that namespace names should be valid IRIs (though it
> doesn't make it an error if they aren't).

I think that's reasonable.

> However, I do feel this syntax is a bit more fragile in that it overloads use
> of existing symbols. Using a new character such as back-tick would give less
> risk of future problems extending the grammar, and less danger of poor error
> messages for incorrect queries.

I agree, but I think it's a risk worth taking to use a syntax that most people
using XML already understand.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Thursday, 9 July 2009 13:25:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:14:57 GMT