W3C home > Mailing lists > Public > public-qt-comments@w3.org > July 2005

[Bug 1368] [XQuery] some editorial comments on 3.2 Path Expressions

From: <bugzilla@wiggum.w3.org>
Date: Sat, 09 Jul 2005 22:53:56 +0000
To: public-qt-comments@w3.org
Cc:
Message-Id: <E1DrOCq-0004a6-Uo@wiggum.w3.org>

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





------- Additional Comments From scott_boag@us.ibm.com  2005-07-09 22:53 -------
(In reply to comment #0)
> 3.2 Path Expressions
> 
> 'Note: The "/" character can be used either as an individual token'
>     Change "individual token" to "complete path expression".

done.

> 
> 'or as part of a pattern such as "/*".'
>     Change "part of a pattern" to "the beginning of a longer path expression".

done.

> 
>     Add: "Also, '*' is both the multiply operator and a wildcard in path
>     expressions."

done.

> 
> "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.)

done.

> 
> 'For example, "/*" and "/ *" are valid path expressions containing wildcards,
> but "/*5" and "/ * 5" raise parsing errors."
>     Change "parsing errors" to "syntax errors".

done.

> 
>     The phrase "For example" isn't really appropriate: the sentence doesn't give
>     examples of parsing difficulties, it gives the results of their solution.

They're examples of behavior in my opinion.

>     (The solution being to decree that some EBNF-derived forms are valid, and
>     some are not.)

Added "This is resolved using the <loc
href="#parse-note-leading-lone-slash">leading-lone-slash </loc> constraint."
before the sentence. 

> 
>     So it isn't clear *why* the latter forms raise errors.
> 
>     This note appears to restrict the language, which a note should not do.

This is an in-exposition summary of the leading-loan-slash constraint.

>     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 ..."

Right, which is does now.

> 
> '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 "*"

ok, used left hand side.
Received on Saturday, 9 July 2005 22:53:59 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:25 UTC