Re: Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))

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

 



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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

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