From: Pete Resnick <presnick(_at_)qualcomm(_dot_)com>
This week we've heard complaints that pagination and line-breaking
in the .txt RFCs is rigid, as if that were a bug instead of a vital
feature.
Consider the problem of answering the question "Is the RFC on my
screen or printer the same as your document? Was either version
edited by someone or something?"
So when I read an RFC on my Palm and all of the line breaks are in
different places, or when Sam Hartman listens to an RFC with a
text-to-speech engine, the fact that it is not the "same" as your
document (for your implied values of "same") is seen as a "vital
feature" and not a bug? I'm sorry, Vern, but this argument is utter
nonsense.
We're even because I think it's at bset nosense to talk about knowingly
and willfully locally rewriting a .txt document as if it were similar
to the automagic reformating of XML and HTML . You and Sam Hartman
know what you're doing to an RFC, or at least that you're doing it.
No use of a browser really knows anything about what went into the
rendering engine.
Though I do oppose immediately converting the RFC archive
to XML for all sorts of reasons, the fact that a markup language
allows you to output identical content in different formats is not
one of those reasons.
*If* a restricted form of XML (or any markup language) could be shown
to reliably preserve semantic content of a standard (and pagination
and line-breaks should never be a part of semantic content)
In theory pagination and line-breaks are not parts of semantic content,
but as with most superfical, simplistic theories, practice differs.
And I'm not talking about the obvious effects on packet and state
diagrams of pagination or line length changes.
but could
produce output for different environments, I'd consider that a big
feature. The problem is that it will take some serious work to get an
appropriately restricted form of such a markup language to make it
reasonable as the canonical form of standards documents. But I think
this small step of making XML available in the I-Ds is a good thing
for other reasons and might give us enough info to tell whether XML
would be viable in the long run for RFCs.
Showing that two different presenations of a document have the same
semantic value sounds close to a Halting Problem, unless you define
"semantic content" vacuously. Just defining what you mean by semantics
is hard.
Take your text-to-speech or Palm examples. Are you really claiming
that a protocol RFC with packet and state diagrams stripped from its
XML source by a "user friendly" browser has its intended meaning?
No one can predict what any XML or HTML browser will do with XLM in
all likely evironments, no matter how restricted the DTD. The only
way you could hope to make such predictions is to so restict the
enviroment of the rendering system that you would have the equivalent
of .txt, while carrying around the bugs in the million of lines of
code in an IE or Mozilla.
Vernon Schryver vjs(_at_)rhyolite(_dot_)com