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

nico at cryptonector.com (Nico Williams) Fri, 23 January 2015 23:17 UTC

From: "nico at cryptonector.com"
Date: Fri, 23 Jan 2015 17:17:40 -0600
Subject: [rfc-i] v3imp #8 Fragment tagging on sourcecode
In-Reply-To: <54C2D525.8000609@alum.mit.edu>
References: <20150123175511.GI2350@localhost> <54C28E3F.4040901@alum.mit.edu> <20150123181608.GJ2350@localhost> <54C294FC.5000204@alum.mit.edu> <20150123190759.GK2350@localhost> <54C2A4AF.6040108@seantek.com> <D8E02C3B-8C62-47D7-8947-B6B679DADD03@fugue.com> <54C2C021.3060909@alum.mit.edu> <20150123224935.GN2350@localhost> <54C2D525.8000609@alum.mit.edu>
Message-ID: <20150123231735.GP2350@localhost>

On Fri, Jan 23, 2015 at 06:11:33PM -0500, Paul Kyzivat wrote:
> On 1/23/15 5:49 PM, Nico Williams wrote:
> >IMO the right thing to do is to define markup in modules of various
> >types, to be interpreted only by the xml2rfc processor, and which is to
> >be used to define chunks (named by anchors) to be extracted into figures
> >that call for them (by anchor).
> 
> I'm not following you. Are you talking about markup specific to each
> 'type', or a single markup for all types that might be embedded in
> drafts?

ASN.1 could look like:

  -- <xml2rfc:fragment anchor="Foo">
  Foo ::= SEQUENCE {
    ...
  }
  -- </xml2rfc:fragment anchor="Foo">

Yes, a bit ugly (OK, *very* ugly), but it would allow the author to keep
all of a module in a single, cohesive file, without having to go update
a bunch of figures every time he or she has to make a significant change
(e.g., add a prefix to all defined entity names).

> A generic one seems a step too far to me. And doing it on a
> type-specific basis isn't in scope here.

It could be generic.

> I have indeed considered extending ABNF syntax with 'include' syntax
> and rulename scoping. This would not be "markup" - it would be first
> class syntax within ABNF. It could be defined so that 'include'
> references could be resolved to a module defined within a draft/rfc
> and extracted as needed. And it could handle self references to
> other modules within the document doing the including.

Agreed.  ABNF needs a notion of modules, imports, and exports.  Like
ASN.1.  Use URNs not OIDs to name modules though!  :)

Nico
--