[rfc-i] xml2rfc vs html and others

[John R Levine]

> I'm fine with people using XML2RFC to generate a new RFC format, but I 
> think requiring these to be converted back into XML2RFC is too 
> constraining.

Oh, I agree there, too.  The XML is the real document, the converted 
versions are display formats.  I expect there will be lots of ways get the 
XML, ranging from us weenies who edit it in emacs to XML structure editors 
to translations from Word to hand markup.  The production staff does hand 
markup of text drafts now, this wouldn't be a lot of new work, although we 
could save them time if we'd get over our irrational fear of XML.

> I would even prefer the situation where we require XML2RFC source along 
> with the RFCng during a transition phase (that could take a year or two) 
> over the two-way conversion requirement.

Perhaps, although I still see nothing that is likely to work as well as 
xml2rfc.

Constrained HTML might have minor advantages as a display format but it 
would be a nightmare as a working format.  HTML suffers from being both a 
structure language and a display language.  Every HTML editor I've seen 
only treats it as a display language, i.e., add arbitrary crud to the HTML 
to try and make the display look OK.  I honestly don't know how you expect 
to create HTML that meets the constraints other than by hand editing. 
Editing HTML by hand is definitely not an improvement over doing it in XML.

XML wysiwyg editors, while often klunkier, use DTDs and adhere to the 
DTD's structure.  You don't have to use one (I don't), but they exist as a 
proof of concept.

Regards,
John Levine, johnl at taugh.com, Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.