> From: Pete Resnick <presnick@qualcomm.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@rhyolite.com