- From: <bugzilla@wiggum.w3.org>
- Date: Wed, 11 May 2005 07:14:33 +0000
- To: public-qt-comments@w3.org
- Cc:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=1368 Summary: [XQuery] some editorial comments on 3.2 Path Expressions Product: XPath / XQuery / XSLT Version: Last Call drafts Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: XQuery AssignedTo: chamberl@almaden.ibm.com ReportedBy: jmdyck@ibiblio.org QAContact: public-qt-comments@w3.org 3.2 Path Expressions 'Note: The "/" character can be used either as an individual token' Change "individual token" to "complete path expression". 'or as part of a pattern such as "/*".' Change "part of a pattern" to "the beginning of a longer path expression". Add: "Also, '*' is both the multiply operator and a wildcard in path expressions." "on the left hand side of an operator" Change "an operator" to '"*"'. (Yes, the problem is more general than that, but this note is only talking about the '*' case.) 'For example, "/*" and "/ *" are valid path expressions containing wildcards, but "/*5" and "/ * 5" raise parsing errors." Change "parsing errors" to "syntax errors". The phrase "For example" isn't really appropriate: the sentence doesn't give examples of parsing difficulties, it gives the results of their solution. (The solution being to decree that some EBNF-derived forms are valid, and some are not.) So it isn't clear *why* the latter forms raise errors. This note appears to restrict the language, which a note should not do. So it should refer to the underlying normative text (currently A.1.1 "grammar-note: leading-lone-slash"). E.g.: "As set out in section [blah], these parsing difficulties are avoided by ..." 'Parentheses must be used when "/" is used as the first operand of an operator, as in "(/) * 5".' You probably want to avoid talking in terms of operands. For instance, in $x union / * 5 the first operand of the '*' is $x union / (a UnionExpr). So "/" is not the first operand of the '*', so the "parentheses must be used" sentence does not fire. And yet you probably want it to, because the parsing difficulty is presumably there. Instead, it's better to stick to "/" on the left hand side of "*" or "/" followed by "*"
Received on Wednesday, 11 May 2005 07:14:42 UTC