Subject: Re: path-legacy (bareword) and toplabel in A ~ B

From: [email-masked] (Kai Henningsen)
Date: 05 Mar 2006 20:25:00 +0200

[email-masked] (Harald Tveit Alvestrand)  wrote on 16.01.06 in <[email-masked]>:

> --On mandag, januar 16, 2006 14:40:42 +0100 Frank Ellermann
> <[email-masked]> wrote:
>
> > Your 2822 optional-field example is interesting.  So we _can_
> > have some "catch-all" rules and similar ambiguities, as long
> > as they come after all matching more specific alternatives.
>
> I think ABNF is actually silent on the subject; the running code seems to
> be "ambiguous grammars are OK, you have to look at the text to figure out
> how to resolve them".
>
> Ugly....

The obvious way to do this is to say if it matches a more specific rule  
and a more general rule, interpret it as matching the more specific rule.  
It certainly is *NOT* to rely on what comes first in the text.

Rule A is more specific than rule B if rule B matches everything that rule  
A does, but rule A does *not* match everything that rule B does. Example:  
A = *digit; B = *alphanum; A is more specific than B because every digit  
sequence is an alphanum sequence but not the other way around, and 123 is  
A and not B under this interpretation.

If it matches two rules where one is not more specific than the other,  
either it needs text explaining what it means, or it's a grammar bug. Or  
maybe we'd need an exception for syntactic sugar without inherent semantic  
meaning, where the semantic comes out the same no matter which alternative  
it's taken to match (such as FWS, commas, or the like, being grouped to  
the right or to the left)?

See it as similar to the idea to go for the longest possible match.

MfG Kai