Thank you for your attention to this issue. I came across it when trying to
interpret the "leading-lone-slash" constraint. While I have developed some
feeling of what it wants, I can't seem to align this with the actual wording,
mostly because the "keyword" and "operator" subsumptions seem unclear
to me. I would have called axis names "keywords", but they could not
appear after a leading slash then. Also I might not call the keywords
introducing FLWOR clauses "operators", but then these should be allowed
to follow a "lone slash". Finally, the formulation
    "the following token must be a NameTest"
is not suitable for the case where name in question introduces a FunctionCall.
For a distinction of the (leading) slash from the "lone slash", my grammar
tools found these followers that are legal for either according to the BNF:
  followers of slash
    $ ( . .. < <!-- <? @ DecimalLiteral DoubleLiteral IntegerLiteral
    QName StringLiteral Wildcard ancestor ancestor-or-self attribute
    child comment descendant descendant-or-self document
    document-node element following following-sibling node ordered
    parent preceding preceding-sibling processing-instruction
    schema-attribute schema-element self text unordered
  followers of "lone slash"
    != ) * + , - ; < << <= = > >= >> ] and ascending case cast
    castable collation default descending div else empty eq except
    for ge gt idiv instance intersect is le let lt mod ne or order
    return satisfies stable to treat union where | }
    and the end-of-query.
So the need for lookahead arises from both QName and "<", but 
without the extra constraint, there are ambiguities, at least for
  document{<a/>}/(for $x in . order by / ascending return .)
Best regards,

From: [] On Behalf Of Michael Kay
Sent: Monday, June 02, 2008 12:06 AM
To: 'Mailing list for the SAXON XSLT and XQuery processor'
Subject: Re: [saxon] XQuery syntax error

In fact Saxon doesn't accept any kind of constructor (direct or computed) after a leading "/", and it doesn't accept an ordered{} or unordered{} expression either, all of which are legal according to the BNF. 
I think there is room for debate on what is legal here, and I have therefore raised a bug against the spec: see
I won't change the Saxon parser until the WG rules on this bug.
Michael Kay

From: [] On Behalf Of Rademacher, Gunther
Sent: 01 June 2008 21:24
To: Mailing list for the SAXON XSLT and XQuery processor
Subject: [saxon] XQuery syntax error

Saxon's XQuery parser apparently does not accept a direct constructor
following a leading slash in a path expression, as in


The resulting expression may not be particularly useful, but isn't it
valid per the grammar in the XQuery recommendation?

Best regards,

Software AG – Sitz/Registered office: Uhlandstraße 12, 64297 Darmstadt, Germany, – Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/ Management Board: Karl-Heinz Streibich (Vorsitzender/Chairman), David Broadbent, Mark Edwards, Dr. Peter Kürpick,Arnd Zinnhardt; - Aufsichtsratsvorsitzender/ Chairman of the Supervisory Board: Frank F. Beelitz -