[rfc-i] Comment on: draft-crocker-rfc-media-00.txt

[Bob Braden]

>
>
>
>       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 
>characteristic of
>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 
>multiple per
>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 
>from the
>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 
> then
>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.

Bob Braden