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, 24 Jun 2008 23:44:29 +0000
To: public-qt-comments@w3.org
Message-Id: <E1KBIBZ-0000Sz-Qq@wiggum.w3.org>

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





--- Comment #7 from Michael Kay <mike@saxonica.com>  2008-06-24 23:44:29 ---
A couple of points.

Firstly, there's no definition of the term "operator". I don't know if you
regard "else" as an operator, but this ambiguity affects constructs like 

if ($doclevel) then / else /*

Certainly, any normative rules about this situation should not assume the term
"operator" is well defined, any more than the word "keyword" (as used in the
normative constraint).

Secondly, I don't think there's a good reason to ban operators after "/" in
cases where they aren't ambiguous. The cases known to be ambiguous were
operators written as a name ("union", "is", "intersect" are the most likely to
appear in practice), and "*". To this list we must now add "<".

The sentence from the non-normative Note cited in comment #5 is quoted out of
context. Most of the note is concerned with "/" followed by "*". Also, it's
clearly written as a paraphrase of the normative constraint and not intended to
replace or extend the constraint. I don't think it can be read as saying that
implementations must not allow otherwise unambiguous constructs such as 

(/ = $a)

(which I have seen quite often; the author almost certainly intended ((/) is
$a), but that's not the point).

We need to fix the normative constraint to clarify what is meant by a "keyword"
(for example, to make it clear whether /f(x) or /unordered{x} are allowed or
disallowed), and to say something about "/" followed by "<".

I have some sympathy with the argument that we should allow /<a/>, and disallow
/<a, on the grounds that it's more consistent to always take the non-operator
interpretation. The only reservation about this is that "/<a" was legal and
unambguous in XPath 1.0, and is legal and unambiguous is XPath 2.0 - it is only
XQuery that introduces the ambiguity. However, I think it's extremely unlikely
that any real code will be affected.


-- 
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 Tuesday, 24 June 2008 23:45:04 GMT

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