W3C home > Mailing lists > Public > public-qt-comments@w3.org > June 2008

[Bug 5727] [XQuery] Syntax ambiguities with leading "/"

From: <bugzilla@wiggum.w3.org>
Date: Tue, 03 Jun 2008 02:11:20 +0000
CC:
To: public-qt-comments@w3.org
Message-Id: <E1K3Lzc-00040D-8x@wiggum.w3.org>

http://www.w3.org/Bugs/Public/show_bug.cgi?id=5727





------- Comment #4 from jmdyck@ibiblio.org  2008-06-03 02:11 -------
(In reply to comment #0)
>
> Gunther Rademacher, in an email on the saxon-help list [1], has pointed out
> another problem not discussed in this grammar note, which arises when "/" is
> followed by "<". The following expressions are both legal according to the
> XQuery grammar, though only (1) is legal XPath:
> 
> (1) /<a/b
> 
> (2) /<a/>

This is closely related to a case I pointed out about 7 years ago:
http://lists.w3.org/Archives/Public/www-xml-query-comments/2001Jul/0021.html
It was a bona fide grammatical ambiguity, which was resolved by disallowing
cascading RelationalExprs (now ComparisonExprs). I pointed out that that would
still leave conflicts requiring 3 symbols of lookahead to resolve, but
apparently that was deemed acceptable.

> I think it's important that every valid XPath expression should be legal in
> XQuery, so I think that we should either (a) require parsers to accept both
> these constructs (which involves lookahead), or (b) require them to accept
> only (1). This can be achieved by a note at the end of constraint
> leading-lone-slash to the effect:
> 
> "Similarly, a '<' character that follows a leading '/' is always interpreted
> as an operator, and not as the start of a direct constructor."

I think "Conversely" would be clearer than "Similarly", since the proposed
resolution is the opposite of that for "*" and keyword-like tokens.

(Mind you, I think I prefer alternative a.)
Received on Tuesday, 3 June 2008 02:11:53 GMT

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