[abnf-discuss] BNFs and determinism (Re: [art] [Technical Errata Reported] RFC7601 (5435))

[Carsten Bormann <[e-mail]>]

On Jul 23, 2018, at 14:19, Peter Occil <[e-mail]> wrote:
> 
> Thus, whether a received-token parser parses an "atom" as a "word" or as a "domain" depends on the context in which the "atom" appears,

Hi Peter,

actually, this is not how BNF traditionally works.

BNF is a productive grammar that produces a language.

It doesn’t tell you how to “parse”, i.e., assign rules to sections of the strings that make up the language.

E.g.,

  Foo = Bar / Baz

  Bar = “abc”

  Baz = “ab” “c”

is perfectly fine as BNF (here in ABNF form modulo the smartquotes) and takes no position on whether “abc” is a Bar or a Baz; it is certainly part of the language (as is “aBc” but that is a different story).

Clearly, parser generators do generate “parsers" that do want to know, so they are happier if the decision can be made.

When writing software based on ABNF, I generally prefer to use PEG (parse expression grammar) parsers instead of traditional BNF-based parser generators; this sometimes means I have to massage the ABNF slightly.  I also try to deliver my ABNF in PEG-friendly form.  But none of that is supported by RFC 5234 (STD 68).

CDDL (the ABNF derivative for CBOR and JSON) does prefer a clear assignment of specific rules to a subtree of the data model item tree; we are using PEG semantics for this.

BTW, the first RFC to use BNF (without actually using that word) was RFC 5 of June 2, l969 [sic!]; this wasn’t Ken L. Harrenstien's version of BNF but already somewhat close.  Prepare for the “BNF in RFCs” fiftieth anniversary in 10.5 months…

Grüße, Carsten