[rfc-i] Provide a way to manage source files used in generating RFC XML

Nico Williams nico at cryptonector.com
Fri Oct 31 07:59:38 PDT 2014

On Fri, Oct 31, 2014 at 7:00 AM, Carsten Bormann <cabo at tzi.org> wrote:
> Thomas Clausen <ietf at thomasclausen.org> writes:
>> But please don’t impose something as “mandatory, the only way you’re
>> allowed to be doing it” forcing tonnes of people to have to change
>> their workflows, tools, …

It couldn't be mandatory.  XML isn't mandatory now, and there are too
many higher-level file formats (e.g., .lyx, .md) or alternate formats
(e.g., nroff).

> +1.

It should be unnecessary to +1 that, but I do anyways :)

> The main problem with this diversity is that if a number of people from
> different circles want to start collaborating on an RFC, it may be
> additional work for them to agree on a way to do this.  Fortunately,
> RFCXML is the common denominator here.  (To enable this, I actually have
> hacked together a basic upconverter from RFCXML to markdown.  I haven't
> had nearly enough time to finish that yet, though.)

When I've had to I've just switched back to pretty-formatted XML.

I have half of a xml2rfc->lyx XSLT program written.  The idea is to
convert back to an XML representation of .lyx, then apply another
conversion to get proper .lyx.  But I don't have the time for it.

Another possibility would be to work on LyX.  LyX now has an IM system
for collaboration, but ideally it would have real multi-user editing.
Other editors do, so yet another possibility would be to switch to one
of those.

LyX also has edit tracking, which is *really* nice, though it leads to
a token-passing type collaboration.  xml2rfc does not have edit
tracking, so all edits have to be accepted or rejected before lyx2rfc
can be applied to a .lyx with as-yet-unaccepted tracked edits.

(I don't think xml2rfc should grow a vocabulary for edit tracking,
convenient though it would be for me -- it would be too difficult to
use directly.)


More information about the rfc-interest mailing list