[rfc-i] v3imp #8 Fragment tagging on sourcecode

[pkyzivat at alum.mit.edu (Paul Kyzivat)]

On 1/25/15 3:57 AM, Julian Reschke wrote:
> On 2015-01-24 17:59, Sean Leonard wrote:
>> On 1/24/2015 8:21 AM, Sean Leonard wrote:
>>> First of all there is no such thing as "ABNF modules" yet--only ABNF
>>> grammar (combined with specification text). I recognize this
>>> conversation is trending to creating them.
>>> Providing different definitions of the same rule in the same RFC is
>>> reckless
>>
>> The more I thought about this, the more I would like to propose that the
>> RFC itself be unit of analysis (i.e., "module").
>> ...
>
>
> I agree that it's good to formalize this somewhat, but I'm not convinced
> updating/extending RFC 5234 is a good idea.
>
> For instance, in the HTTP specs we use prose rules with a well-defined
> syntax:
>
> <http://greenbytes.de/tech/webdav/rfc7231.html#imported.abnf>
>
> This might be enough for automated checkers to do the right thing.

I agree that we need to be careful not to extend ABNF too much, making 
it more difficult. OTOH, the people who use ABNF are not, for the most 
part, stupid. (Does ABNF need to be understandable to someone who 
doesn't know at least one real programming language?)

The use of some symbols defined in another draft presents a particularly 
interesting issue:

To verify the using ABNF, you need to import at least the rule defining 
the symbol in question. But that rule may well refer to other rules in 
the referenced document. Should you:

- selectively import rules that are needed, one by one, until there
   are no more undefined symbols?

- OR, simply import the full set of rules from the referenced document?

Either way, there may then be conflicts between rules defined in the new 
document and those imported from the old document. The potential is 
greater if you have imported all the ABNF from the referenced document.

And this of course depends a bit on whether the ABNF in the referenced 
document was intended to be one "module" or not.

RFC5234 is itself an interesting case study. It includes:

- a set of "Core Rules" in Appendix B. This could be viewed as one
   ABNF "module".
- a complete ABNF definition of ABNF. This could also be viewed as
   a separate ABNF "module", but it informally indicates that it
   depends (imports) the Core Rules.
- ABNF fragments interspersed with text, duplicating rules in
   both of the above.

*Many* uses of ABNF reuse rules defined in the Core Rules. When doing 
so, it would probably be fine to import the full set of Core Rules, but 
it would probably be inappropriate to also import the rules defining the 
ABNF of ABNF, and it certainly would be inappropriate to also import all 
the fragments.

IMO it would make sense to introduce enough new syntax to ABNF to define 
named modules, and to specify the import of specific named modules from 
an external document.

	Thanks,
	Paul