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

Nico Williams nico at cryptonector.com
Fri Jan 23 15:17:40 PST 2015


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


More information about the rfc-interest mailing list