ietf
[Top] [All Lists]

Re: A modest proposal - allow the ID repository to hold xml

2003-09-03 02:33:18
On Wed, 3 Sep 2003, Jari Arkko wrote:

I'd very much like to allow the submission of XML to the
I-D directories.

However, in addition I'd like to actually allow the
submission of HTML, generated by xml2rfc. Why? Because
I'd really like to browse most drafts through my browser,
jump to sections,  find the references easily etc. And without
performing any extra steps by myself.

One of the primary reasons for proposing XML as the canonical RFC format
is that these other formats (ASCII text, HTML, PDF/Postscript,
refer/indxbib, SQL, Tektronix 4013) can be derived from the XML source.

Presumably the RFC editor would publish the XML document as the
authoritative version, and would also generate and publish (from the XML)
alternative copies in the ASCII text, PDF, and HTML formats.

This satisfies the "plain ASCII text rules" bigots (in which camp I am
still firmly entrenched) while taking advantage of the markup and linking
facilities provided by PDF and HTML. (I've completely given up hope that
Microsoft will ever acknowledge that non-flowed text/plain must be
rendered with a mono-spaced font, fifty years of prior art be damned, eh?)

(It may be that this is possible via XML as well -- I'm
not expert in XML so I can't tell if its readily supported
by everyone's browser without loading lots of DTDs. Does
someone know?)

The point of XML is that you don't have to be able to read it. Given an
XML DTD for RFCs, tools can be written that express the XML in pretty much
any format you like. HTML would certainly be one of those formats. (And
for guys like me who live and die by grep, even *I* would buy into an
xmlrfcgrep program that provided grep functionality against "XML-RFC-DTD"
files.)

And all of these submission formats should be allowed if
and only there's a text version to go with it.

Let me go out on a limb and say "No they shouldn't; only XML submissions
should be allowed."



Now that the shrapnel has stopped whizzing past my head, let me explain
why.

The traditional way of writing RFCs is with nroff, typically using a
minimal subset of the -ms macros. In recent years Microsoft Word (along
with other WYSIAWYG software) has invaded the traditional UNIX typesetting
tools workspace to a certain degree (in the context of writing
IETF-related documents). Regardless, other than the occasional Loonie who
formats this stuff purely by hand, we are all already using markup
languages to create these documents. That being the case, XML isn't a new
way of writing these documents, it's just a different one. The current RFC
DTD isn't complicated, and -- as long as it's kept simple[*] -- I don't
see any excuse for people not to use it. Then again, I've been using troff
exclusively for 20 years now, to the point where I can _almost_ see the
consistency of its syntax ...

While there isn't a whole lot I *can't* accomplish in troff, my experience
with using it to write I-Ds suggests that those documents are so
structured that I really just want to write a simple set of macros
tailored for that task. I shudder to think what the Word crowd goes
through in this regard. WYS might be WYG, but the path between the two (in
my very limited experience) is one whose mana will suck the very sanity
from your living soul.

There is no argument to be made against the suitability of XML as the
canonical format for authoring RFCs and drafts. Writing the raw XML might
not be pleasant, but neither is writing raw 'roff (or MS Word) for many
people. Let's embrace this as an opportunity. If we can get the marketing
twits to concentrate on selling GUI XML RFC authoring tools, we just might
be able to distract them from contaminating the actual working groups.

--lyndon

[*] The critical aspect is that the DTD *must* be kept simple. If the DTD
evolves into a Turing machine with Perl-like syntax we can just
acknowledge that it's time to shut down the IETF and go home. I cling to
the forlorn hope that people still know - and more importantly,
understand - what the 'E' in IETF stands for.



<Prev in Thread] Current Thread [Next in Thread>