[Bug 5727] Syntax ambiguities with leading "/"

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

           Summary: Syntax ambiguities with leading "/"
           Product: XPath / XQuery / XSLT
           Version: Recommendation
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XQuery
        AssignedTo: chamberl@almaden.ibm.com
        ReportedBy: mike@saxonica.com
         QAContact: public-qt-comments@w3.org


The constraint "leading-lone-slash" in Appendix A.1.2 discusses the situation
where a leading "/" is followed by a "keyword" (meaning, presumably, an
NCName), or by "*", and indicates that these should always be treated as
NameTests, to avoid the need for lookahead.

I would interpret this as meaning that the construct

/unordered{x}

is an error, even though there is only one way this construct could match the
grammar. However, the reference parser accepts this construct (Saxon does not).

Gunther Rademacher, in an email on the saxon-help list [1], has pointed out
another problem not discussed in this grammar note, which arises when "/" is
followed by "<". The following expressions are both legal according to the
XQuery grammar, though only (1) is legal XPath:

(1) /<a/b

(2) /<a/>

The reference parser for XQuery accepts (2) but not (1), while the reference
parser for XPath accepts (1) but not (2). Saxon accepts (1) but not (2) whether
parsing XPath or XQuery.

I think it's important that every valid XPath expression should be legal in
XQuery, so I think that we should either (a) require parsers to accept both
these constructs (which involves lookahead), or (b) require them to accept only
(1). This can be achieved by a note at the end of constraint leading-lone-slash
to the effect:

"Similarly, a '<' character that follows a leading '/' is always interpreted as
an operator, and not as the start of a direct constructor."

(Both expressions are useless in practice, and I can't conceive of variations
that make them useful. But I think an argument based on utility would also
favour (1) as a marginally more sensible thing to support.)

[1] http://markmail.org/message/lu3c5632os6cvg7l

Received on Sunday, 1 June 2008 22:02:12 UTC