Proposal for EBNF syntax cleanup

[rhdunn]

Initial draft.

[michaelhkay]

I think it's important to demonstrate that any revision to the EBNF is technically viable in terms of the parser-generator technology used by the XQuery WG to validate the grammar and generate the reference parsers used in the grammar "applets" and for generating the XQueryX machinery. I don't personally have hands-on experience of this technology, but I know that it's very good at spotting ambiguities in proposed syntax changes that would otherwise easily go unnoticed.

[rhdunn]

I think that is a useful idea.

I've added an annotation to the grammar section to reflect the state of that section (i.e. that it is a proposed grammar, and has not been formally verified). I have also added more text explaining where these changes are coming from and what the implementation experience of these changes are.

This specific proposed change (and several others) are coming from changes I have made in my XQuery plugin and more formally documented in the plugin documentation. As such, I am documenting the grammar that my plugin is using. I will be updating my plugin to reflect any changes made to the grammar during the standardisation process.

I'm also going by the instructions in the proposal template:

Optional. You could describe your extension in terms of EBNF, and bonus points if you describe how it fits into the existing EBNF of XPath ;-)

[michaelhkay]

The syntax for QuantifiedExpression in XPath is different from XQuery - doesn't allow the "as" clause.

Generally I'm not convinced by the rationale for these changes. It's been a long-standing debate whether the grammar should be optimized for parser-writers or for query-authors, and the justification stated here seems to assume the former (not that I see anything greatly wrong with the changes; they just seem a bit gratuitous). If you're trying to optimize for parser-writers, I strongly suspect that changes that make parser writing easier using one technology will make it more difficult using another.

Changes to the EBNF can easily have unforeseen effects, for example breaking the auto-generated W3C parser that's built from the XML machine-readable master grammar.

[rhdunn]

That makes sense. I'm happy for this proposal to be withdrawn.

I'm leaving this open, as I don't know what the procedure for withdrawal is (e.g. if there needs to be a consensus).

[adamretter]

So I don't think the EBNF should be modified to reflect a parser.

Having written a couple of XPath parsers using different parser generators, whilst you try hard to have your parser rules directly mirror the EBNF, different tools put different constraints on you, and permit different levels of expressiveness. In my experience, you often have to merge some grammar statement from the EBNF together or add some intermediary grammar statements to be able to extract the objects you need.

I think the EBNF should recommend an abstract grammar that is both understandable and implementable.

In terms of the "applets" that @michaelhkay mentions, I think that @liamquin might be able to point you to those.

@rhdunn If you do want to withdraw the proposal, just close the PR with a comment saying something like "Withdrawn due to concerns" or similar.

[rhdunn]

Withdrawn due to concerns.