RE: Alternative formats for IDs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



  *> 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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]