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

pkyzivat at alum.mit.edu (Paul Kyzivat) Sat, 24 January 2015 15:45 UTC

From: "pkyzivat at alum.mit.edu"
Date: Sat, 24 Jan 2015 10:45:10 -0500
Subject: [rfc-i] v3imp #8 Fragment tagging on sourcecode
In-Reply-To: <54C3576A.9030206@greenbytes.de>
References: <54C20F92.4090400@seantek.com> <54C232FC.1000604@gmx.de> <54C275BC.1040905@alum.mit.edu> <20150123175511.GI2350@localhost> <54C28E3F.4040901@alum.mit.edu> <E378C876-5217-4274-86B6-1DBFB653DE24@vpnc.org> <54C29891.6040101@alum.mit.edu> <54C3576A.9030206@greenbytes.de>
Message-ID: <54C3BE06.8010707@alum.mit.edu>

On 1/24/15 3:27 AM, Julian Reschke wrote:
> On 2015-01-23 19:53, Paul Kyzivat wrote:
>> On 1/23/15 1:39 PM, Paul Hoffman wrote:
>>> On Jan 23, 2015, at 10:09 AM, Paul Kyzivat <pkyzivat at alum.mit.edu>
>>> wrote:
>>>> Different strokes for different folks.
>>>
>>> That's the problem. Sean is asking for a one-size-fits-all approach,
>>> without suggesting actual examples of a proposed solution.
>>>
>>>> This *can* work.
>>>
>>> By "work", I think of "is the solution understandable to a typical
>>> Internet Draft author", and here things fall apart. It is possible to
>>> mark artwork as a fragment; it may not be possible to sanely say what
>>> it is a fragment of. Many RFCs have multiple ABNF modules or ASN.1
>>> modules, so there would have to be some way to say "this is a fragment
>>> of that module" *and* say "and the whole goes in this particular order".
>>>
>>>> It would work much better if you could automatically extract the
>>>> collection of fragments when you want to process it.
>>>
>>> Fully agree. If we can come up with a way to help that automation
>>> while not confusing document authors, this seems worthwhile. However,
>>> complexity seems to be a negative here.
>>
>> As I suggested earlier, the simplest thing I can think of here would be
>> specify that if multiple artwork elements have the same name attribute,
>> then the expectation is that they should be concatenated when extracted.
>>
>> Then, as long as you specify the same type for all the elements with the
>> same name, a verifier for that type can process it.
>>
>> If you have a number of independent ABNF modules, then just give them
>> different names.
>
> +1. And it's possible in v2 already.

It is *possible*, but it requires those writing drafts containing ABNF 
and those making tools to agree on some conventions. I'd like to see 
those conventions documented, and perhaps enforced by IdNits.

	Thanks,
	Paul