Re: [abnf-discuss] Importing ABNF rules

[Paul Kyzivat <[e-mail]>]

Isn't there an effort to improve/automate verification of language usage 
embedded in drafts? (Or did I imagine that?)

If so, mechanisms for formalizing inport & extension of ABNF could fit 
within that effort.

	Thanks,
	Paul

On 9/20/23 2:52 PM, Dave Crocker wrote:
> On 9/20/2023 11:25 AM, Paul Kyzivat wrote:
>> But because there is a practical need to "import"/"copy" rules from 
>> one spec to another and 5234 doesn't provide one, various ad hoc 
>> mechanisms for specifying this have evolved across multiple documents. 
>> Some are:
> 
> the 'how' of specifying importation can vary.  personally, I don't care 
> how it's done as long as it is clear and easy for an average reader to 
> understand unambiguously.
> 
> 
>> 1) verbage in the explanatory text of the document explaining that 
>> certain rules are to be taken from another document
>>
>> 2) an ABNF comment explaining the same thing
>>
>> 3) use of a prose-val, such as:
>>     CHAR = <as defined in RFC5234>
>>
>> I generally prefer (3) when only a few rules are needed and their 
>> definitions don't reference lots of other rules. If the situation is 
>> more complex then I generally use (2).
> 
> It's also common to have a section early in the document that sets up 
> terminology definitions and importations. (This might be your 1) but the 
> section I'm referencing is more than explanatory.
> 
> 
>> It can be hard to verify the ABNF in a document that extends the ABNF 
>> of another document. It is necessary to actually cut and paste to 
>> create the composite ABNF grammar and then check it. (Or implement it.)
> 
> Point taken.  On the other hand, repeating the details of a rule 
> specification from another spec invites divergence, as specifications 
> evolve.
> 
> 
>>
>> I would *like* to see ABNF extended to have a more formal mechanism 
>> for importation of ABNF, and for extension of ABNF grammars. This 
>> would facilitate automatic verification of ABNF in documents. But I'm 
>> dubious whether there is sufficient interest to pursue this. 
> 
> Yes it would.  I think that every idea for enhancement I've ever seen 
> for ABNF was entirely reasonable and, generally, so were the proposed 
> details.
> 
> At the purely technical level, my main criticism is a tendency to want 
> to put enhancements into the core set of rules.  I like a core to be as 
> simple as possible, while covering 'essential' capability, in order to 
> reduce effort and problems with common implementation.
> 
> Something can be a good idea, and have community support, but not be 
> widely needed.  Then it makes sense to standardize it but not as part of 
> the core set.
> 
> At that highlights the non-technical issue, which I think is why many 
> reasonable proposed enhancements have not been adopted:  lack of a 
> critical mass of community support.
> 
> 
> d/
>