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

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

On 1/23/2015 11:08 AM, Nico Williams wrote:
> On Fri, Jan 23, 2015 at 01:37:48PM -0500, Paul Kyzivat wrote:
>> Sure, but without a standard way to do it you need a custom
>> extractor for every draft. In the case of ABNF, which is widely used
>> in drafts, it would be highly desirable to have a single tool that
>> could verify the ABNF in any draft.
> It's not just about verifying.  It's also about compiling (e.g., ASN.1
> modules).  I want to be able to extract the bloody thing.

[Various other posts noted]

The gist of Improvement #8 (in light of Improvements #5 and #6) is 
straightforward:

I believe that the status-quo of figure extraction and restitching is 
"bunk". "Bunk" is a term of art that means "technically bankrupt". 
Possibly morally bankrupt too. And basically fraught with error.

The best way to reduce transcription errors is to provide complete, 
normative modules so that transcription is not necessary to use the 
standard. I have been extracting ASN.1 modules from RFCs for many years 
now, with various tools; it's a tedious job.

To eliminate transcription errors, don't attempt to stitch disparate 
<sourcecode> and <artwork> elements together. The standards author 
SHOULD provide normative modules, such as in <attachment> elements. 
Making sure that "inline" content (<sourcecode> and <artwork>) matches 
normative "attachment" content is an editorial matter.


On 1/23/2015 10:37 AM, Paul Kyzivat wrote:
> Sure, but without a standard way to do it you need a custom extractor 
> for every draft. In the case of ABNF, which is widely used in drafts, 
> it would be highly desirable to have a single tool that could verify 
> the ABNF in any draft.
>
> Also, the tagging in 5403 diminishes the readability of the draft. 
> Consider how much less readable RFC5234 would be if you did that.

I believe that ABNF is a special case for three reasons:
1) it is kind of the lingua franca of the IETF,
2) there is no convention to put ABNF in code modules, as there is with 
other languages (Python, JSON, ASN.1, DTD, RELAX schema, etc.), and
3) ABNF is comprised of simple declarative statements -- each statement 
is self-contained (except to the extent that it references other 
production names). Unlike ASN.1 or C/C++, for example, there are no 
imports, preprocessor directives, function prototypes, class 
definitions, or macros.

Therefore, we should consider ABNF specially...to the point of creating 
a new tag <abnf>, a new in-text convention <prod type="abnf">, or at 
least understanding that "stitching" <sourcecode type="abnf"> pieces is 
acceptable in a way that other types are not.

I request that conversations about ABNF go under "Improvement #3 
Verbatim text". (Which also satisfies Julian's complaint about 
demonstrated uses.) I will continue that conversation under that thread.

Sean