- 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