[rfc-i] Comment on: draft-crocker-rfc-media-00.txt
braden at ISI.EDU
Sat Sep 27 15:08:17 PDT 2008
> My proposal derives from existing practice with xml2rfc. I only
> offer some
>conventions for naming the files that hold external figures, in order to have
>the related files easily associated with the master file.
Errr... I don't believe in the implication <existing code> => <user interface>
Surely, the implication goes the other way: <user interface> => <old/new code>.
If we believe that a different convention would be better for users, I am sure
the XML2RFC folks would find a way to handle it. They have been reasonably
responsive in the past.
>(I should comment that xml2rfc produces html with the spiffy
>reverting to the provided ascii art, if the external file is not found.)
This may be a spiffy feature during I-D development, but it is definitely not
spiffy for published RFCs. You are building in a potential error, without
telling the user.
>Further, the convention of having one figure per file, rather than
>file, shows up regularly, such as the output of html by MS Office and (if I'm
>interpreting the file properly, OpenOffice) as well as being what html does.
Large numbers of small files would be a nightmare. Surely you are not going
to tell me that it must be right because Microsoft does it. When you purchase
a book, you don't expect to be handed a bound copy of text and a pile of
separate one-page figures. Do you?
>Hence, what your proposal does is to seek to invent yet-another multiplexing
>technique. In this case, it is one which forces figures to be separate
>text that refers to them, rather than permitting in-line mixing.
Sorry, I don't follow that.
>In summary, the enhancements that my draft proposes to yours are:
> 1. Adding the option of having the master file be in xml2rfc which
>automatically produces alternative formats, such as txt, html and pdf.
I believe it is a well-settled question that xml2rfc is a great boost to
those who choose
to use it, but in no way is it required.
> 2. Specifying external figures, etc., as one-per-file
I missed that you REQUIRE figures to be one-per-file. Much worse,I think.
More information about the rfc-interest