- From: <bugzilla@wiggum.w3.org>
- Date: Tue, 24 Jun 2008 23:44:29 +0000
- To: public-qt-comments@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 UTC