Hi -
From: "Julian Reschke" <julian(_dot_)reschke(_at_)gmx(_dot_)de>
To: "Randy Presuhn" <randy_presuhn(_at_)mindspring(_dot_)com>
Cc: "IETF Discussion Mailing List" <ietf(_at_)ietf(_dot_)org>
Sent: Wednesday, July 15, 2009 2:13 AM
Subject: Re: Automatically updated Table of Contents with Nroff
...
For editing a document, particularly a largish one, the availability of
.so is for me nroff's biggest advantage over xml2rfc.
...
How exactly is that an advantage of xml2rfc?
That's my point. It's a capability xml2rfc lacked, at least the last time
I used it. For the user to be able to split stuff up into multiple files
is a huge advantage which should be familiar to any programmer.
Examples from my own experience: It's cleaner to be able to keep mib
modules in a separate files, rather than extracting it from a formatted
document. This is particularly true when there are multiple MIB modules
in a document. Common references (especially for a bundle of inter-related
I-Ds, but also for RFCs) can be handled as macros that result in mnemonic
values showing up both in the source and in the generated output. This
is especially useful when one RFC is replaced with another: one little
edit to the file of reference macros, rather than going through the whole
bundle of source files. Finally, it is a much cleaner way to handle
boilerplate,
particularly if you want to use configuration management software for
your sources and have a "paper trail" of boilerplate changes.
Now, it is true the RFC editor wanted nroff sources in the form of a single
file. Fortunately, this is trivial to produce at publication time using soelim
or equivalent.
Randy
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf