Re: [apps-discuss] draft-yevstifeyev-abnf-separated-lists-01.txt

[John C Klensin <[e-mail]>]

--On Monday, December 06, 2010 13:08 -0500 Tony Hansen
<[e-mail]> wrote:

> I think it would be useful to find ABNF constructs in existing
> protocols that provide for lists and give examples of how
> their ABNF would have been simplified if this new ABNF
> construct were available.

and

--On Monday, December 06, 2010 13:19 -0500 Barry Leiba
<[e-mail]> wrote:

> I agree with Tony that if you can't include examples of how we
> should have had this before, it'll be hard to convince the
> community and the IESG that it's needed now.  We can always
> come up with things that *might* be useful, but part of the
> challenge is keeping the language as simple as possible (and
> no simpler).

And _that_, it seems to me, is the more fundamental problem with
this proposal.  One can always add more elements, constructors,
or decorations to a metalanguage like this one.  One can also go
minimalist: while some things would be quite tedious to express,
I don't believe there is anything that can be expressed in RFC
5234 ABNF, with or without this extension, that cannot be
expressed in classical/original BNF.   The advantage of a more
powerful metalanguage is that expressions become more concise,
often leading to greater clarity for those who understand it.
The disadvantage is that the language becomes harder to write
optimally and _much_ harder to examine for errors and debug.
Empirically, ABNF has already become daunting enough that we
need to talk about ABNF experts in the IETF, that people
routinely get grammars written in ABNF wrong, and that it is not
a metalanguage that most of those who can otherwise write specs
in the IETF feel that they can use efficiently and accurately.  

The question shouldn't be whether we can describe a new feature
of find syntax for it.   It should be whether that new feature
is really important enough to justify the additional complexity
it adds to the metalanguage, especially if the chosen syntax
makes the metalanguage more subtle and/or obscure.

IMO, that case has not been made at all convincingly yet.  The
sorts of examples that Barry and Tony suggest would be a useful
step in the process of convincing people, but I suggest that,
unless it can be shown that this construction actually
simplifies a large number of practical cases, every error we
find in the ABNF when documents that use the metalanguage are
examine is an argument against more operators and complexity.

    john