>> There is not currently a version of xml2rfc that meets our >> needs.
I do not recall seeing any input from the RFC Editor, on the XML2RFC mailing list, citing xml2rfc's deficiencies.
That makes it difficult to get those deficiencies fixed.
Please, please, please. Post those deficiencies to that list.
Absolutely.
> The > issue arises from handing you a format that contains generic > markup and is editable but, because of your "via nroff" process, > requires authors to deduce substantive and editorial changes > from diffs and then retrofit them back into the XML for future > use.
This point has been made a number of times, recently. Its importance appears to remain under-appreciated.
IETF documents are subject to revision by new editors. They currently find it difficult or impossible to ensure that they are starting from the correct master version.
These are issues even when the editor doesn't change.
To the extent that they must start from the .txt version, they have significant startup costs (with significant potential for introducing new errors) in order to convert the document to a format better suited to editing -- e.g., better able to manipulate the document's structure.
What the IETF community needs is to be able to obtain an accurate, revisable-form version of published documents. xml2rfc is the best candidate for that form. We therefore need to find a way for the RFC Editor to maintain the master version of RFCs in that form.
While I agree that this needs to be the goal, when the RFC does use xml2rfc for most of the editing process getting back a revised XML spec from the RFC Editor that has all the changes made prior to the nroff step would be a HUGE improvement. The time needed to retrofit all the RFC Editor changes into the XML is nonnegligable - I wish I didn't epeak from recent experience, but I do. For once let's not let the best be the enemy of the good. Ned _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf