Nearly all ebnf files failed to work? about kgt HOT 4 CLOSED

This is true - there are several different dialects, all of which people call "ebnf". Those examples are other people's various different things I've found, which (confusingly) all get called "ebnf".

I didn't want to implement parsers for dialects unless there is a clear specification to follow. I don't want to accidentally invent yet more dialects.

I think we should split the ebnf dialect into separate parsers:

• W3C's own EBNF: https://www.w3.org/TR/REC-xml/#sec-notation - this does not use semicolons, or commas between concatenated terms. The W3C are also wildly inconsistent - see https://lists.w3.org/Archives/Public/spec-prod/2006JanMar/0017.html;
• BS EBNF: BS 6154 - (withdrawn) which does require a comma. Brief overview here: http://csci.csusb.edu/dick/cs320/comp.text.Meta.html#BS6154
• ISO/IEC 14977 : 1996(E) - there's a brief description of it here: https://www.cl.cam.ac.uk/~mgk25/iso-14977-paper.pdf

Then we could figure out which examples are supposed to be which dialect, and rename them accordingly.

from kgt.

@perlawk which ebnf dialect would you like to use?

from kgt.

Renamed the ebnf dialect to iso-ebnf in 94137d5. This is ISO/IEC 14977 : 1996(E).

expr-minus.iso-ebnf and json.iso-ebnf are the only examples in the ISO dialect. The other .ebnf examples are some other ebnf dialect.

Note ebnf2.ebnf is probably intended to be ISO EBNF, but technically incorrect; the standard requires an empty newline to separate productions. I imagine the author did not realise that, or have a way to validate it.

from kgt.

I'm closing this because the EBNF dialect was split to multiple dialects. I'm sure there are bugs to fix for all of them.

from kgt.