This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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 "*"
Please note that "*" is not the only operator that causes problems after "/". Even more problematic is "union", in expressions such as / union /* Michael Kay (personal response)
Yup, keyword operators like 'union' were what I had in mind when I said "(Yes, the problem is more general than that, but this note is only talking about the '*' case.)" In my alternate wording in Bug 1390, I cover both "*" and keywords. Mind you, I missed the ambiguity, which is a stronger argument. I'll go tack on an amendment.
(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.
A joint meeting of the Query and XSLT working groups considered this comment on July 20, 2005. The WGs agreed to resolve these editorial issues as listed in my previous comment. If you do not agree with this resolution, please add a comment explaining why. If you wish to appeal the WG's decision to the Director, then change the Status of the record to Reopened. If we do not hear from you in the next two weeks, we will assume you agree with the WG decision.
Closing bug because commenter has not objected to the resolution posted and more than two weeks have passed.