[rfc-i] Provide a way to manage source files used in generating RFC XML
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
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
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
More information about the rfc-interest