On 18 mrt 2010, at 20:59, Julian Reschke wrote:
The XML in itself can't be interpreted by a human to the level needed to
create a compliant implementation, although it deceptively looks like maybe
it could. Of course human readability also doesn't exist for pretty much
anything other than text or the simplest of HTML, in itself this isn't a
show stopper.
That is simply incorrect, which can easily be checked by looking at the XML
source of a spec.
People make mistakes implementing today's text. If they have to implement from
XML source where they have to interpret things like escape codes and numbered
lists (just to mention the first two things that come to mind) in their head
this is going to be much worse.
There is at least one other implementation that can be used by everybody
who's got a current browser
So now I have to have a working network connection to read an RFC? What if the
site that hosts all this goes down? What if someone wants to read a spec 20
years from now?
it would be impossible to have all RFCs be available in one format if XML is
adopted for future RFCs.
Yes. How is that a problem, exactly?
Because this doubles the amount of effort needed to be able to read RFCs.
And if old RFCs can be in text, why not new ones? And if some RFCs are text,
why not derive text versions of the XML ones too, so there are text versions of
all of them? And if there are text versions for all RFCs and XML versions of
only some, why not make the text version authoritative? Oh wait...
That's a pretty good result for files which date back as long as 40 years.
Good luck finding any other document format of the same age with that
property.
That may be true, but that features comes with drawbacks.
Drawbacks that we can all agree on?
Sure, RFCs don't look too pretty, and their hard line and page endings are very
annoying because they never fit the screen or paper that you happen to use.
(Aside: PDF is much worse in this regard.) But pretty much all RFCs can be
viewed in HTML versions which don't have these problems by anyone who cares.
Being able to have names and examples in non-latin characters would be nice,
but for names this is just a cosmetic thing with compatibility issues that make
it not worth the trouble, and with examples it's dangerous to depend on correct
display of anything that isn't 7-bit ASCII because it's still quite easy to end
up with something that's incorrect or doesn't show.
The ability to use graphics would be helpful but would have severe consequences
for the file format, having to use multiple files to make up a single RFC would
be problematic (ASCII, HTML with images) and single file formats aren't
trivially decoded. Images are also very hard to edit, making collaboration and
especially updating RFCs much more difficult. And the inclusion of images
reduces the number of devices that can display an RFC significantly. (Line
printers, text only displays and remote login sessions are out, hand held
devices also to a large degree because the screens probably don't have enough
resolution.)
I guess plain ASCII isn't so bad after all. Would be nice if we could get rid
of the pagination, though.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf