On 20-jun-2006, at 1:07, Ned Freed wrote:
does the
RFC editor really live up to his/her name and perform extensive
edits?
The answer is it depends. I've had some documents that were pretty
much
unchanged while others were edited quite extensively. In recent
work I've
observed that most edits are good ones, but occasionally the RFC
Editor doesn't
quite get what's going on and bolixes something up. It is therefore
imperative
that every change be carefully reviewed by the document authors.
I see.
> No matter how good my tools are, I'm going to have to do
> considerable, mostly manual, work to retrofit those changes into
> my source.
I don't know what other authors do, but I edit all the changes back
into my
xml2rfc source, iterating until my output matches, modulo numbering
and
paragraphing and whatnot, what the RFC Editor produced.
Ouch!
That must be a colossal waste of time for everyone involved.
The RFC Editor provides an annotated differences listing showing
you what
changed between your final draft and what's in the actual RFC. It
is a simple
matter to duplicate this tool and use it to tweak your sources to
match the
actual RFC. I've tried using change bars and other fancier tools,
but I have
concluded they're more trouble than they're worth.
Then you haven't been doing it right... If you use Word, for instance
(but Open Office has the same functionality) you can set up "track
changes" and "highlight changes when editing" or words to the same
effect, and then you'll see text that's added in a different color
depending on who added it, and you can reject or accept changes made
by others. You can also easily skip to the next edit. I can't imagine
two or more people working on the same document without this
functionality.
Yes, this makes sense. Especially if the Word format is only used as
a "lingua franca" without depending on specific details. I.e., I can
write a text in Open Office, tag it with the right styles and export
to .doc format.
My immediate thought in response to all this is "what a colossal
waste of
time". I want to focus on document content, not stylistic frills
and irrelevant
minutiae. That's what the RFC Editors gets the big bucks to do... I
therefore
want a tool that lets me engage in semantic markup with as little
attention
paid to layout issues as possible.
And that's exactly what the style mechanism is for: you can indicate
headings of different levels (= generate numbering and table of
contents automatically), have different kinds of lists (bulleted,
numbered) and so on.
It is exceedingly unfortunate that some
amount of device-level markup is still needed in xml2rfc, but
hopefully as the
tools improve over time actual use of such facilites will become less
necessary.
Speaking of time wasting: it doesn't make much sense to me to work on
a tool specifically for this purpose while much more powerful general
purpose tools are readily available. I.e., wouldn't it make sense to
move towards a situation where it's possible to write a draft or RFC
with a regular word processor with only a little post processing
rather than spend time perfecting yet another tool that's hard to learn?
THis is not to say there aren't cases where I want precise control
of document
output.
I don't care about that (well, obviously to some degree, but not
much). As an author, I mark up my text correctly and then the layout
people can do their magic and get it right about 98% of the time.
> So I suggest that, generally, we would find
> that, in a "text plus figures" model, the editing process would
> generally change the text only, permitting the figures/images to
> remain unchanged.
That is not my experience. Figures are very hard to get right, they
very often require edits.
It depends on what sort of edits you're talking about. Both figures
and equations move things away from pure semantic markup and towards
presentation specifics. It's unavoidable, and once you enter the
presentation
realm the list of possible tweaks to make things just a little bit
better often seems endless.
I'm talking about stuff like "the text in this box should be A but
it's B" and "there shouldn't be a line between those two boxes".
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf