- From: <bugzilla@wiggum.w3.org>
- Date: Tue, 03 Jun 2008 02:11:20 +0000
- To: public-qt-comments@w3.org
- CC:
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 UTC