Re: [abnf-discuss] constrained-01 - advantage?

[Sean Leonard <[e-mail]>]

> On Nov 14, 2016, at 12:26 PM, Doug Royer <[e-mail]> wrote:
> 
> On 11/13/2016 04:21 PM, Sean Leonard wrote:
> 
>>> …
>> 
>> Well:
>> 
>>> resent-field    = "Resent-" field-name ":" unstructured CRLF
>> 
>> 
>> Is simpler than:
>> 
>>> resent-field  = resent-unstructured / resent-date / resent-from / resent-sender / ...
>> 
>> 
>> First of all, it looks simpler, because it is.
>> 
>> Second of all, <resent-date>, <resent-from>, <resent-sender> etc. are all “subsumed” in <resent-unstructured>, leading to an intentionally ambiguous grammar. The problem with the existing way of writing things out, is that the former are all superfluous when the latter is present. Another way to write it tends to be:
>> 
>>  field = date / from / sender / … / extension-field
>> 
>>  extension-field = field-name ":" unstructured CRLF
>> 
>> Well it makes perfect sense when you read it, of course,
> > but when a computer / parser parses productions, every <date> is going
> > to match with <extension-field> as well. The point being
> > <extension-field> is not really doing what you think it’s doing in ABNF:
> > it’s really <any-and-every-field>.
> > ...
>> There is nothing “wrong” with creating an ambiguous grammar,
> > but it can lead to subtle parsing errors if you are not careful.
> > Usually ambiguous grammars are undesirable because you want your
> > code to go down one, and only one, path. An automated ABNF validator
> > should be able to detect ambiguous grammars and inform you about that.
> 
> If your talking about replacing ABNF with new syntax. then I would agree. To a person reading the ABNF, they mean the same thing.
> At no point is one path more important than another.
> 
> Unless you deprecate the old method, its not going to help.
> Because people will use which ever makes sense to them.

I suppose that deprecating the old method would be something on the table to discuss. I believe it is desirable to avoid ambiguous grammars. At the same time, a sufficiently sophisticated tool could be written to identify these sorts of cases (of intentionally ambiguous grammars for parameterized names and values).

> Is the goal of this draft to make all future ABNF in RFC's parsable by a computer program? To mandate it?  I did not understand that after reading the draft.
> 
> If this keeps going, it will be a new ASN.1

We don’t want that. But the idea of “Table Constraints” is an ASN.1 term. (It is also a SQL concept, because, surprise, it’s about constraining data to tables of values.)

One thing is that none of the drafts that are being proposed change the context-free nature of ABNF.

I would say that a goal is that ABNF in RFCs should be easy to validate, and this would include by means of computer programs. This increases document quality. I recognize that there is a spectrum of views around here about how “formal” ABNF ought to be.

Regards,

Sean