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

[Julian Reschke <[e-mail]>]

On 2016-11-14 00:21, 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.
>
>
> When you actually go to program what the ABNF represents, most people are not going to program:
>
> if (chars[0] = ‘d’ && chars[1] = ‘a’ & chars[2] = ’t’ & chars[3] = ‘e’ & chars[4] = ‘:’) {
>   // parse as date
> } else if (chars[0] = ‘f’ …) {
>   // parse as from
> } else if (…) {
>   // ...
> } else {
>   field-name = everything before ‘:’;
>   unstructured = everything between ‘:’ and CRLF;
> }
> ...

If this is the only use case (is it?), then I'd say that you're dealing 
with a problem you could avoid in the first place.

See how RFC 7230 distinguishes between parsing the HTTP message info 
fields and field values, and then has completely *separate* ABNFs for 
each field value.

Best regards, Julian