[rfc-i] v3imp #8 Fragment tagging on sourcecode
dev+ietf at seantek.com
Fri Jan 23 11:44:47 PST 2015
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
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.
More information about the rfc-interest