Michael,
Please remember the following minor issues:
(1) xml2rfc may be widely used, but it is not a requirement or a
standard. It actually has no formal status in the IETF. Even
the informational RFC that describes it is long out of date.
All of that is reasonable for the way it is being used today,
but is not consistent with your proposal.
(2) People do prepare I-Ds and input to the RFC Editor in other
ways. Plain ASCII text prepared with an editor, nroff, and,
using other sets of tools, MS Word are all in use and there may
be others that I don't know about. The specification in the
image file document are compatible with all of these as well as
with xml2rfc (plus or minus some changes or post-processing).
(3) While one can debate it at length --and we, no doubt, will
have to do that-- the other graphic and specification mechanisms
you cite do not have either the track record or external
acceptance to make a reasonable guarantee of long-term stability.
john
--On Tuesday, 26 August, 2008 17:30 +0100 michael(_dot_)dillon(_at_)bt(_dot_)com
wrote:
On first reading this seems to be an interesting way to go.
It seems to be heading in the right general direction, but
I wonder why it does not concentrate on specifying inputs
rather than outputs. Given that XML is now widely used as the
input format for RFCs, it seems worthwhile to review the bits
of XML-related stuff that are mature enough for use for
writers.
For instance, SVG for diagrams and PNG for images, standard
CSS for tables.
Of course, there has to be a defined standard reporitory output
for "publishing" the RFCs, but that already seems to be PS/PDF.
If the IETF defines a standard input format, and the XML2RFC
toolset is updated to support that toolset and output PS/PDF
format for the repository, then that takes care of the format
issue. Then there is only one file, not two or three. And the
toolset could feasibly generate a text file plus PS/PDF images
only format, as an alternate output if that is desired. Or SWF
output files, or TGZ file with a folder containing HTML and
separate files for each SVG diagram or PNG image. No need to
choose, just prioritise.
Stylistic issues are quite separate, although they should
probably also be specified up front if it keeps things more
orderly. I'd suggest avoiding numbering images/diagrams in
favor of naming them. E.g. see diagram former-state-machine or
refer to image original-napkin-notes.
--Michael Dillon
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf