*> From john-ietf@xxxxxxx Wed Jan 11 13:53:32 2006 *> X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham *> version=3.1.0 *> Date: Wed, 11 Jan 2006 16:52:31 -0500 *> From: John C Klensin <john-ietf@xxxxxxx> *> To: Bob Braden <braden@xxxxxxx>, paul.hoffman@xxxxxxxx, br@xxxxxxxxxxxxxx *> cc: ietf@xxxxxxxx *> Subject: RE: Alternative formats for IDs *> Content-Transfer-Encoding: 7bit *> X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean *> *> *> *> --On Wednesday, 11 January, 2006 13:02 -0800 Bob Braden *> <braden@xxxxxxx> wrote: *> *> > *> The RFC editor has some problems which have not, to my *> > knowledge, *> been enumerated. *> > *> *> > *> > Your knowledge is apparently incomplete. The RFC Editor has *> > been actively experimenting with using xml2rfc for *> > publication, and we have been passing our problems along to *> > the tools team. As we get more experience, new ones show up. *> > There is not currently a version of xml2rfc that meets our *> > needs. Some of our editors do the major editing in XML, but *> Bob, *> *> Let me suggest a way to look at the above, deriving in large *> measure from the experiences Ned Freed and I (mostly Ned, who *> did the heavy lifting) had with what are now RFCs 4288 and 4289. *> To the extent to which authors can hand XML to you, and get XML *> back with whatever substantive/ editorial changes you have made, *> it should ultimately not be a concern of anyone in the community *> how you make the transition between the final XML, with all of *> the text worked out, and the final formatting. In particular, *> if that step requires you to convert the XML to nroff and then *> massage the nroff, I don't think it should be an issue. 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. John, We have thought about what you suggest, and it may be workable. The problem with it is this: during the "AUTH48" stage, we give the author(s) the exact final version ready for publication, for final verification. (There was a time when this was mostly pro forma, but for a variety of reasons, some good and some bad, the AUTH48 stagetoday not infrequently invovles significant changes to a document.) Suppose that we edit the document in XML (we are already doing this part of the time), do a final nroffing pass to get the format just right, and then give the author(s) the edited xml, final .txt, and a diff file. (We could easily do this today). The author(s) change the .xml (or give us a patch file for us to make the changes.) We have to make a new nroff version and PUT THE SAME CHANGES INTO IT THAT WE DID THE FIRST TIME. Now, this may not actually be too bad; most of the changes at the nroff stage are very cosmetic, and we could use diffs and perhaps other tools to make it quite easy. OR, we could change the AUTH48 policy to let the author(s) deal only with the edited xml, without the final formatting cleanups. We would then translate to nroff and do the final formatting AFTER AUTH48. (Or, we could have two stages of AUTH48). Perhaps we should run some more experiments. Bob Braden for the RFC Editor _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf