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

[dev+ietf at seantek.com (Sean Leonard)]

On 1/24/2015 7:45 AM, Paul Kyzivat wrote:
> 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.

-?

Like Paul I am ambivalent.

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.

To use Julian's language, are there "concrete examples" of a discrete 
RFC containing "independent ABNF modules"? Unless you have a different 
definition, I am going with "independent ABNF modules" means ABNF 
definitions that are mutually conflicting, so that implementation of one 
necessarily precludes implementation of the other.

In my own work, I provide different names for the rule. For example, in 
draft-josefsson-pkix-textual there are rules {textualmsg}, 
{stricttextualmsg}, and {laxtextualmsg}.

Providing different definitions of the same rule in the same RFC is 
reckless--I don't see a good reason for normative text in a standard to 
do such a thing. Furthermore, there is no harm in an ABNF processor (and 
I have not seen any such implementations that are commercially viable) 
generating code to handle all of the rules in an RFC, then excising or 
ignoring the rules that you don't make use of.

I don't have a problem with the naming convention to use the same name 
to concatenate <artwork>/<sourcecode> text. However, that raises 
questions about what happens if you use the same name on things that are 
not plain text, such as SVG artwork. I think a better convention 
(idNit-enforced) is that each @name in the document SHOULD be distinct.

Sean