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

[nico at cryptonector.com (Nico Williams)]

On Fri, Jan 23, 2015 at 11:44:47AM -0800, Sean Leonard wrote:
> 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.

I would reserve such language for real outrages.

> 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.

I agree with the sentiment.  Where's your proposal?

(I made a proposal, in broad strokes, not a specific proposal.)

BTW, this stuff has been discussed many times.

> To eliminate transcription errors, don't attempt to stitch disparate
> <sourcecode> and <artwork> elements together. The standards author

Sure.

> SHOULD provide normative modules, such as in <attachment> elements.

Maybe.  The module will need some markup, markup that works with the
language's comments, so that figures can pull portions of a module.

> Making sure that "inline" content (<sourcecode> and <artwork>)
> matches normative "attachment" content is an editorial matter.

That's a hefty burden on the document author, on reviewers, and on the
RFC-Editor.

What you're proposing can be done trivially with a bit of build
scripting today.  Moving that into the processor won't make the tasks of
authoring, reviewing, and editing, substantially better, therefore I see
little value in it.

> 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.

Eh, no.  People have used ASN.1 without modules.  You can say that's
wrong all you like (I would too, because it is), but it's happened.
JSON has no modules (nor any schema language that we agree on, for that
matter).  And so on.

ABNF should not be special in any way other than "maybe the processor
has built-in validation functionality for it" [because that's relatively
simple to code for].  Ideally there would be validator HTTP/whatever
APIs for ASN.1 and so on, then we could all use our favorite, and the
xml2rfc processor could support all of them.

Actually, that's an idea: add configuration elements for defining
validator URLs for various languages, then the xml2rfc processor can use
them.  I't d be pretty simple: POST to the given URL with an appropriate
MIME type; 200 means OK, and so on.  We define the API, others provide
implementations for ASN.1 etcetera.  It'd be easy to implement an ASN.1
validator that uses asn1c or Heimdal's ASN.1 compiler, say.

> Therefore, we should consider ABNF specially...to the point of
> creating a new tag <abnf>, [...]

I don't this proposal to be outrageous, just nauseating.

>                     [...], 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.

What do you mean "in-text"?

Nico
--