- 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