Re: Why XML is perferable
Stephen McHenry wrote: On a more serious note, having done a lot of instruction over the years, it shouldn't be about ego (I paid my "understanding dues" - everyone else should too!!), it should be about communication... i.e., how quickly can we effectively communicate complex concepts... In theory, I agree; we need to write protocol specs that can be read. However, I would put greater emphasis on precision than on speed. Reading a diagram can be faster than reading text; but text can be more precise. A picture may be worth a thousand words; the problem is that you can't be sure what most of those words are, because they come out of your reader's cultural context. -- /\ |John Stracke| http://www.ecal.com |My opinions are my own. | |Chief Scientist |===| |eCal Corp. |A ship is safe in a harbor, but that's not what| |[EMAIL PROTECTED]|a ship is for. | \/
Re: Why XML is perferable
At 06:39 PM 2/24/2001, Scott Brim wrote: On Sat, Feb 24, 2001 at 04:47:42PM -0800, Eliot Lear wrote: You know, the people on this list make great computer scientists, network architects, application and protocol designers. I'm not so sure how many of us understand CHI. Some of us like to think we do, but I suspect very few of us actually do. So, given this, why don't we ask some people who really DO understand this problem to come up with a decent recommendation, rather than perennially flaming about it? Then we can ask them to help us with NATs ;-) But CHI is only a secondary issue. The primary issue is the best format for archives. We want something which is not likely to be superceded by something better in a few years. Well, respectfully, I disagree... Only I don't think (in this case) CHI stands for Computer Human Interface, I think rather it should stand for Communication Human Interface... If the archives were able to contain the content of the communication - renderable by whatever display limitations/personal preferences were applicable at each moment - then we would have truly achieved something... Somehow, I have this idea that I'm talking to a list of the best and brightest of our industry... that we have (collectively) engineered protocols that allow communications using wires and wireless, that have enabled things that were impossible within the memory of most present here... So, now let's up the ante. Communication is more than bits on a wire. At the highest sense, it's the ability to move information from the brain of one individual to the brain of another. Are we, as computer scientists, incapable of coming up with a format that allows us to describe very rich content (including text, images, animated images, even 3D images (and animated ones - 6 degrees of freedom), etc. - whatever it takes...) and then to render it appropriately for displays that range from capable to incapable... Wouldn't this be a better thing for us to be working on than fighting over whether we should keep everything in ASCII...??? From, One who totally doesn't get it... :-) Stephen Stephen McHenry e-mail: [EMAIL PROTECTED] www.cacheware.com
Re: Why XML is perferable
% us understand CHI. Some of us like to think we do, but I suspect very few % % But CHI is only a secondary issue. The primary issue is the best format % for archives. We want something which is not likely to be superceded by % something better in a few years. % % Well, respectfully, I disagree... Only I don't think (in this case) CHI % stands for Computer Human Interface, I think rather it should stand for % Communication Human Interface... % Hum... And I thought it stood for Chicago --bill
Re: Why XML is perferable
In message [EMAIL PROTECTED], Stephen McHenry typed On a more serious note, having done a lot of instruction over the years, it shouldn't be about ego (I paid my "understanding dues" - everyone else should too!!), it should be about communication... i.e., how quickly can we effectively communicate complex concepts... excellent point one of the bigest contributions to the internet standards process was Rich Stevens (RIP) TCP/IP _Illustrated_ series - these clarify, disambiguate and communicate many many areas of standards - i agree wit hbob that protocol creators may not need the visualisation and graphic detail in the early stages, but as you say, there are lots of people implementing who need rapid ways of absorbing the ideas - however, that doesn't mean this has to be in the i-d and RFC stages - it can be in a myriad of other places such as books and trade press journals where articles abound giving the further interpretation - and do say in many languages too cheers j.
Re: Why XML is perferable
* well-known, but some RFCs such as those on OSPF may be much * more vivid if written in XML. There have been quite a few Vivid? We are talking about deeply complex technical documents here, not MTV. What do you mean, "vivid"? Maybe, we can display, say, an example of routing information flow, vividly. Putting a hyperlink to a GIF animation in the XML document would works. No MTV required. And I believe it will help the programmers/protocol implementors. Sincerely, Jun-an Gao.
Re: Why XML is perferable
Jun'an Gao wrote: * well-known, but some RFCs such as those on OSPF may be much * more vivid if written in XML. There have been quite a few Vivid? We are talking about deeply complex technical documents here, not MTV. What do you mean, "vivid"? Maybe, we can display, say, an example of routing information flow, vividly. Putting a hyperlink to a GIF animation in the XML document would works. Pointing to where? Should active Internet connectivity be necessary to read an RFC? Even if a "local"/file URL is specified, how can this compound document get distributed via Email ... mailers vary greatly in how they deal with attachments. I definitely see the potential value in HTML/XML *annotated* RFCs. But they should be an additional expression of what is in the ASCII. cheers -- Sean
Re: Why XML is perferable
At 08:16 24/02/2001 -0800, Sean Finn wrote: Even if a "local"/file URL is specified, how can this compound document get distributed via Email ... mailers vary greatly in how they deal with attachments. MHTML specification, RFC 2557. The only (AFAIK) compound document format within our repertoire. If we accept HTML or any other format with natural embedded references (and don't outlaw their use), RFC 2557 is the least bad alternative I know. -- Harald Tveit Alvestrand, [EMAIL PROTECTED] +47 41 44 29 94 Personal email: [EMAIL PROTECTED]
Re: Why XML is perferable
* From [EMAIL PROTECTED] Sat Feb 24 06:15:16 2001 * To: [EMAIL PROTECTED] * Subject: Re: Why XML is perferable * Date: Sat, 24 Feb 2001 21:51:56 +0800 (CST) * From: [EMAIL PROTECTED] (Jun'an Gao) * X-Loop: [EMAIL PROTECTED] * * * well-known, but some RFCs such as those on OSPF may be much * * more vivid if written in XML. There have been quite a few * * * Vivid? We are talking about deeply complex technical documents * here, not MTV. What do you mean, "vivid"? * * Maybe, we can display, say, an example of routing information flow, * vividly. Putting a hyperlink to a GIF animation in the XML document * would works. No MTV required. And I believe it will help the * programmers/protocol implementors. * * * Sincerely, * Jun-an Gao. * * Surely you jest. Animated GIF? How did you get through school without having your algebra dance on a screen? We can color the independent variables red, the functions green, and ... The serious protocol implementors I know construct their own private "gif"s on whiteboards and in their heads, and they get by without animation. Sheesh. Bob Braden
Re: Why XML is perferable: manipulating and presentation
I hated ITU, but because now I can get ITU documents freely, Well, I've never hated the ITU, though I'm not sure the feeling is mutual. I consider myself a long-term friend of this august organization and have even served in the voluntary Friends of the ITU Auxiliary Standards Corps Organization. If you register on the ITU site, you can get up to 3 documents free, but you may not redistribute those documents (except as printed copies within the physical confines of your premises). After your three free documents, you pay on a retail basis. This is certainly a step in the right direction, though I'd be happier with n=3000 than n=3. An interesting contrasting policy is the U.S. Patent Office where you can get many documents free, and then pay for the full images. However, once you've covered their "incremental costs", you are free to redistribute those documents at will. Of course, bulk access to the USPTO database is not yet available and it appears that this bulk service will be provided by outside parties. Even more interesting contrasts are the IETF and the U.S. SEC where you can obtain all documents for free and redistribute at will. I don't hate it any more. Hate is not very productive, though long-term bewilderment seems to be near universal in this case. Regards, Carl
Re: Why XML is perferable
At 12:20 PM 2/24/2001, Bob Braden wrote: Surely you jest. Animated GIF? How did you get through school without having your algebra dance on a screen? We can color the independent variables red, the functions green, and ... Hey, that's not a bad idea. The serious protocol implementors I know construct their own private "gif"s on whiteboards and in their heads, and they get by without animation. Sheesh. SARCASM Hey, real serious protocol implementors don't need no stinkin' animation. We don't need no stinkin' pictures. In fact, we don't need no stinking English either. Just give us the equations and the state matrix. Anybody that can't just understand that? Well, screw 'em!! /SARCASM On a more serious note, having done a lot of instruction over the years, it shouldn't be about ego (I paid my "understanding dues" - everyone else should too!!), it should be about communication... i.e., how quickly can we effectively communicate complex concepts... I have waded my way through lots of documents (RFCs and some really incomprehensible stuff too) over the years and it isn't (or shouldn't be) about whether or not you have the intellectual fortitude to wade through and figure it out, it should be about how quickly can you communicate those concepts to others. Why take an hour if 45 min will suffice? Why take 6 hours if 1.5 will do? The sooner it's clear, the sooner I can begin implementing it. The clearer it is, the less likely I am to make any errors of understanding. The quicker I can implement a correct version, the sooner I can start on the next thing I work on... all of which adds up to the more I can accomplish in a given period of time. It seems to me that what we really need is a truly representation independent form of content, both words and pictures (both still and moving) that is renderable according to user preferences on any specific device, taking into account the limitations of the device. XML isn't completely that, but it's closer than ASCII, or html, or other forms. But, it's a long way short of what I could personally dream of... OTOH, you might feel the same way another person did who responded (privately) to my previous post with: "You totally fail to get it. " Could be... Wait! I think I still have an ASR-33 in the basement!! I think I hear it calling... Stephen Stephen McHenry VP, Engineering/CTO Cacheware, Inc. 655 Campbell Technology Pkwy, Suite 150 Campbell, CA 95008 Ph: (408) 540-1270 Fax: (408) 540-1305 e-mail: [EMAIL PROTECTED] www.cacheware.com
Re: Why XML is perferable
One additional consideration, the poster had a .cn address. If a graph will help with language/translation issues so much the better. -Ren On Sat, 24 February 2001, Stephen McHenry wrote: At 12:20 PM 2/24/2001, Bob Braden wrote: Surely you jest. Animated GIF? How did you get through school without having your algebra dance on a screen? We can color the independent variables red, the functions green, and ... Hey, that's not a bad idea. repeats snipped -Ren http://www.i-regatta.org
Re: Why XML is perferable
You know, the people on this list make great computer scientists, network architects, application and protocol designers. I'm not so sure how many of us understand CHI. Some of us like to think we do, but I suspect very few of us actually do. So, given this, why don't we ask some people who really DO understand this problem to come up with a decent recommendation, rather than perennially flaming about it? Then we can ask them to help us with NATs ;-)
Re: Why XML is perferable
On Sat, Feb 24, 2001 at 04:47:42PM -0800, Eliot Lear wrote: You know, the people on this list make great computer scientists, network architects, application and protocol designers. I'm not so sure how many of us understand CHI. Some of us like to think we do, but I suspect very few of us actually do. So, given this, why don't we ask some people who really DO understand this problem to come up with a decent recommendation, rather than perennially flaming about it? Then we can ask them to help us with NATs ;-) But CHI is only a secondary issue. The primary issue is the best format for archives. We want something which is not likely to be superceded by something better in a few years. So far there's only one alternative. Others, like XML DTDs, are promising but still have too much vulnerability. ...Scott
RE: Why XML is perferable
All,
Let's consider a few basic principles.
1. Neither ASCII nor XML are ever displayed. They are CODES for
representing characters in a computer. It is the CHARACTERS ( glyphs ) that
are displayed ( presented / rendered ). There is a mapping between the codes
and the glyphs.
2. ASCII has a strictly limited set of characters and glyphs ( even the
"international" version ), which can not represent many languages in the
world, and does a poor job of rendering diagrams, pictures, etc.
3. As some people have emphasised, the importance of ASCII lies in the (
American Standard Code for Information ) INTERCHANGE. Interchange implies
the ability to transfer in a manner which can be understood by both parties
to the transfer. The MOST COMMON global method of transferring will be the
most effective.
4. Interchange does not guarantee understanding - either of presentation
format or content. I wouldn't like to have to deal with Einstein's Theory
of Relativity ( content ), especially in Chinese ( format ). ASCII does not
interchange Chinese characters, so it's presentation format is NOT readily
understandable by "most people".
5. A more comprehensive coding scheme, such as the Universal Character Set
( ISO 10646 ) would allow many more characters and glyphs to be used.
6. The key to usage of encoding schemes is how widely they can be
interpreted by character presentation ( or rendering ) applications ( word
processors, etc. ), in mapping the internal codes to the glyphs rendered on
the screen or on paper. Applications which can render more characters would
allow the use of larger code ranges and more characters.
Until something replaces ASCII as the most commonly available global
interchange format ( and could it be HTML / XML ? ), it will remain the
default. That doesn't mean that we should just accept it for evermore. If
that principle were followed, we would still be drawing on cave walls and
large red rock formations ( Ayres in Australia ! ), which are not very
transportable !
One of the things that the IETF could, and in my opinion SHOULD, do it to
make its documents available in several presentation formats, not to say
languages. Yes, we would still need a master copy and format, which could
be ASCII, but other, more presentable formats, would make life easier for
many people. The ITU-T ( I'm sorry to mention it, but they have been doing
this for decades ) publishes its documents in three languages. If the IETF
is really working for the world, it should take a more global view and
consider a similar sort of policy. Don't we have a work stream on
internationalisation ?
Of course, this sort of effort costs money - lots of it. That's why the
ITU-T charges for documents. If you want it free, you take the IETF
approach and get the inexpensive, ASCII, American language version.
Regards,
Graham Travers
* - Email: [EMAIL PROTECTED]
-Original Message-
From: Jorge Amodio [SMTP:[EMAIL PROTECTED]]
Sent: Friday, February 23, 2001 6:34 AM
To: [EMAIL PROTECTED]
Subject: Re: Why XML is perferable
Wang Xianzhu wrote:
to render XML documents to pure text presentation. There will be
^^^
converters from XML to HTML, ms word, ps, pdf and any other types of
presentation, suitable for any type of readers.
Meanwhile I stick with ASCII, which I can grep, cut paste.
Also I don't think it will be at all practical to drive email
discussions
for ietf drafts if we have to start using XML/HTML/SGML/*ML crap.
BTW, there are RFCs (1125, 1129, etc.) only available in ps format, and
some
provided both text and ps versions. ASCII text is not enough to
describe
information.
Well it worked fine for 2800+ documents and how many today ?
implementations
of tcp/ip protocols running on how many devices ?
I wonder if anyone can write a readable pure text version of ITU-T
P.861.
What P.861 {Objective quality measurement of telephone-band (300-3400
Hz)
speech codecs} has to do with tcp/ip and rfc's ???
BTW, I hate to pay for ITU documents what are supposed to be public (I
still
remember the years old discussion when they ceased to exist available
for anon ftp)
Regards
Jorge.
RE: Why XML is perferable
-Original Message- From: Wang Xianzhu [SMTP:[EMAIL PROTECTED]] Sent: Friday, February 23, 2001 9:13 AM To: ietf Subject: Why XML is perferable Well it worked fine for 2800+ documents and how many today ? 3060+ today, with many ugly figures in '-', '_', 'o', '/', '\' chars, which is very difficult to read. In XML, you can even search for figures if we develop unified Internet/flowchart/etc DTDs. Yes, fine - if you happen to like messy diagrams; are not Chinese, Japanese, Korean, Arabic, ... BTW, I hate to pay for ITU documents what are supposed to be public (I still remember the years old discussion when they ceased to exist available for anon ftp) I hate ITU too. :) Nice to see some reasoned argument for a change ! Regards Jorge. Regards, Wang Xianzhu
Re: Why XML is perferable
In message [EMAIL PROTECTED], gra [EMAIL PROTECTED] typed: Let's consider a few basic principles. ok - lots of good points below - a few responses... 1. Neither ASCII nor XML are ever displayed. They are CODES for representing characters in a computer. It is the CHARACTERS ( glyphs ) that are displayed ( presented / rendered ). There is a mapping between the codes and the glyphs. but the glyphs are in HARDWARE in many devices(e.g. printed on keycaps, in printer wheels, in crt display chips etc)... 2. ASCII has a strictly limited set of characters and glyphs ( even the "international" version ), which can not represent many languages in the world, and does a poor job of rendering diagrams, pictures, etc. yes, this point has been made a lot - however, the discipline of getting a diagram into ascii art has OFTEN caused people in the ietf to udnerstand the problem better (e.g. by choosing the most parsimonious topology to explain a partiocular routing problem) 3. As some people have emphasised, the importance of ASCII lies in the ( American Standard Code for Information ) INTERCHANGE. Interchange implies the ability to transfer in a manner which can be understood by both parties to the transfer. The MOST COMMON global method of transferring will be the most effective. yes, yes, and yes..but also, collating, indexing, and searching - manmy of the search engines are optimised to the roman alhpabet, the english dictionary, and the english freqeuncy distribution of words 4. Interchange does not guarantee understanding - either of presentation format or content. I wouldn't like to have to deal with Einstein's Theory of Relativity ( content ), especially in Chinese ( format ). ASCII does not interchange Chinese characters, so it's presentation format is NOT readily understandable by "most people". 5. A more comprehensive coding scheme, such as the Universal Character Set ( ISO 10646 ) would allow many more characters and glyphs to be used. 6. The key to usage of encoding schemes is how widely they can be interpreted by character presentation ( or rendering ) applications ( word processors, etc. ), in mapping the internal codes to the glyphs rendered on the screen or on paper. Applications which can render more characters would allow the use of larger code ranges and more characters. Until something replaces ASCII as the most commonly available global interchange format ( and could it be HTML / XML ? ), it will remain the default. That doesn't mean that we should just accept it for evermore. If that principle were followed, we would still be drawing on cave walls and large red rock formations ( Ayres in Australia ! ), which are not very transportable ! One of the things that the IETF could, and in my opinion SHOULD, do it to make its documents available in several presentation formats, not to say languages. Yes, we would still need a master copy and format, which could be ASCII, but other, more presentable formats, would make life easier for many people. The ITU-T ( I'm sorry to mention it, but they have been doing this for decades ) publishes its documents in three languages. If the IETF is really working for the world, it should take a more global view and consider a similar sort of policy. Don't we have a work stream on internationalisation ? Of course, this sort of effort costs money - lots of it. That's why the ITU-T charges for documents. If you want it free, you take the IETF approach and get the inexpensive, ASCII, American language version. thats why the ITU claims it charges. i think you overstate the contrast. btw, as someone who has written documents in english english for 20 years using ascii codes, i dont see your point about American _language_ - coding for alhpabet doesnt necessarily code for language (ever used greeklish?:-) anyhow, the point about cost is good - basically, do people want to think about a funding model for multi-lingual internet standards...? worth a brief discussion (there are alternates to the ITU charging model, clearly) j.
RE: Why XML is perferable
BTW, I hate to pay for ITU documents what are supposed to be public (I still remember the years old discussion when they ceased to exist available for anon ftp) I hate ITU too. :) Well, it's always useful for religious groups to have a "great satan"... :-) Nice to see some reasoned argument for a change ! Errr...it's not even reasoned See http://www.itu.int/publications/bookshop/how-to-buy.html#free The implications of this are left as an exercise for the clever engineer. Bob -- Robert Shaw [EMAIL PROTECTED] ITU Internet Strategy and Policy Advisor International Telecommunication Union http://www.itu.int Place des Nations, 1211 Geneva, Switzerland
Re: Why XML is perferable
On Fri, 23 Feb 2001 14:08:34 CST, [EMAIL PROTECTED] (Jun'an Gao) said: One can display doesn't necessarily mean one can comprehend. But the *inability* to display it DOES necessarily mean you can't comprehend. -- Valdis Kletnieks Operating Systems Analyst Virginia Tech PGP signature
Re: Why XML is perferable
* well-known, but some RFCs such as those on OSPF may be much * more vivid if written in XML. There have been quite a few Vivid? We are talking about deeply complex technical documents here, not MTV. What do you mean, "vivid"? Bob Braden
Re: Why XML is perferable: manipulating and presentation
I was wondering if you could tell me something. What would the output of the
p.861 document look like if it were converted from XML to ASCII?
I think the process of documents should have two phases:
1. write, store, transfer, update, manage... , manipulating based on the
logical contents.
2. read, some presentation on devices to make people comprehend.
We read a document on different devices, with different limitations, and
we see different presentation of the documents, but all kinds of the
presentations are based on the contents of the documents. Too make
presentation more effective, we should define a format to write and store
the documents. If the format is defined to be enough good (such as a
well-defined XML DTD for RFCs), the documents encoded in this
format can be easily converted into different kinds of presentation,
to meet the requirements of different people and devices. The process
of convertation can be transparent to the readers. For example, if the
XML DTD and style sheets are defined by IETF, we can get .txt,
.ps, .pdf, .html,... RFCs directly from ietf web and FTP site, while the
authors only compose them according to the defined XML DTD, not
caring about the presentation.
However, certain devices (e.g. pure text readers) still have some
limitations on presentation. For P.861, it seems no way to present it in
pure text format to make people clearly comprehend. This just
proves my opinion: pure text is not suitable for manipulating documents.
Additionally, a goot format of documents greatly ease the work to manipulate
the documents.
I believe that RFCs have a internal format. Documents in this format
are without the page numbers, headers and footers. This format is for
manipulating. The format we see in the published RFCs is only for
reading. Why don't we switch this internal format to XML?
My advice is to: manipulate RFCs in XML/SGML (by carefully
defining a DTD), and automaticlly publish them in every kind
of presentation (by defining different style sheets). This does not
conflict with current situation: txt lovers can still get txt RFCs
from the same location, while others can get html, ps, pdf,... RFCs.
I hated ITU, but because now I can get ITU documents freely,
I don't hate it any more.
Regards,
Wang Xianzhu
RUNWAY Technology
Beijing, China
(This is my last augument about XML.)
-Original Message-
From: Wang Xianzhu [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 23, 2001 4:13 AM
To: [EMAIL PROTECTED]
Subject: Why XML is perferable
to render XML documents to pure text presentation. There will be
^^^
converters from XML to HTML, ms word, ps, pdf and any other types of
presentation, suitable for any type of readers.
Meanwhile I stick with ASCII, which I can grep, cut paste.
1. You can easily get a very well-formed ASCII file from a XML file.
2. With XML, you can not only grep, cut paste, but also manage and process
it.
For example, I can grep XML files for whose level 2 headings containing
the string 'file transfer protocol'. But for ASCII files, this is
impossible, because
1) the computer program does not know where are level 2 headings
2) the string may be split into two lines, grep fails in this situation.
Also I don't think it will be at all practical to drive email
discussions
for ietf drafts if we have to start using XML/HTML/SGML/*ML crap.
BTW, there are RFCs (1125, 1129, etc.) only available in ps format, and
some
provided both text and ps versions. ASCII text is not enough to
describe
information.
Well it worked fine for 2800+ documents and how many today ?
3060+ today, with many ugly figures in '-', '_', 'o', '/', '\' chars, which
is very difficult to read. In XML, you can even search for figures if
we develop unified Internet/flowchart/etc DTDs.
implementations
of tcp/ip protocols running on how many devices ?
I wonder if anyone can write a readable pure text version of ITU-T
P.861.
What P.861 {Objective quality measurement of telephone-band (300-3400 Hz)
speech codecs} has to do with tcp/ip and rfc's ???
Yes, their content of P.861 seems have nothing to do with RFCs.
P.861 is an informational document, like any RFCs. If a RFC face a
similar problem like P.861, I wonder how it can describe it clearly in
pure text.
XML provides a way to describe information in documents, and can be
easily converted to different types of target formats, such as pure text,
pdf, HTML, etc. Again: XML is not for display.
BTW, I hate to pay for ITU documents what are supposed to be public (I
still
remember the years old discussion when they ceased to exist available
for anon ftp)
I hate ITU too. :)
Regards
Jorge.
Regards,
Wang Xianzhu
Re: Why XML is perferable
On Fri, 23 Feb 2001 11:43:02 CST, [EMAIL PROTECTED] (Jun'an Gao) said:
Assumption:
Total Comprehensiveness of RFCs
= SIGMA { interest on RFC#i of reader#j
* familiarity on the presentation format of RFC#i of reader#j
}
Notice that the second term evaluates to:
1 if you can display it effectively.
0 if you can't display it effectively.
Now, if you're willing to give us a pointer *TODAY* to software
that will run on *every* major internet-capable platform, and do a
good-enough job of rendering XML in such a way that it is *more*
understandable than flat-ascii on *all* those platforms, then we'll
talk.
Remember that your XML displayer has to work on a PalmPilot, an
IBM3278 (24x80 text-only monitor) driven by IBM's MVS operating
system (EBCDIC-based, no less), and a DecWriter dot-matrix printer/terminal.
I've personally read ASCII-based RFCs on all those. Oh, and you
have to be able to show value-added - that it does a BETTER job
than ASCII on those 3 devices, as well as everything else
Repeat after me:
Everybody can display ASCII. Until everybody can display XML, we won't
be using XML for the canonical form for RFCs. This is *different* than
what Marshall Rose did in RFC2629 - note that that document is itself
*flat ascii* describing how to write XML and *then convert it to create
a flat ascii RFC*.
Valdis Kletnieks
Operating Systems Analyst
Virginia Tech
Re: Why XML is perferable
It seems we are all discussing the presentation (display, print, read,
etc.) of the document. But the purpose of XML is not presentation (i.e.
XML is not for display), but to make the document more meaningful.
XML can makes series of ASCII characters meaningful to computer programs.
With XML markups, documents can be organized and managed more effectively.
XML documents can be rendered into any types of presentation. If you like
to read RFCs or I-Ds in ASCII format, the web site may provide a converter
to render XML documents to pure text presentation. There will be
converters from XML to HTML, ms word, ps, pdf and any other types of
presentation, suitable for any type of readers.
BTW, there are RFCs (1125, 1129, etc.) only available in ps format, and some
provided both text and ps versions. ASCII text is not enough to describe
information.
I wonder if anyone can write a readable pure text version of ITU-T P.861.
Wang Xianzhu
- Original Message -
From: [EMAIL PROTECTED]
To: "Jun'an Gao" [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, February 23, 2001 12:21 PM
Subject: Re: Why XML is perferable
On Fri, 23 Feb 2001 11:43:02 CST, [EMAIL PROTECTED] (Jun'an Gao) said:
Assumption:
Total Comprehensiveness of RFCs
= SIGMA { interest on RFC#i of reader#j
* familiarity on the presentation format of RFC#i of reader#j
}
Notice that the second term evaluates to:
1 if you can display it effectively.
0 if you can't display it effectively.
Now, if you're willing to give us a pointer *TODAY* to software
that will run on *every* major internet-capable platform, and do a
good-enough job of rendering XML in such a way that it is *more*
understandable than flat-ascii on *all* those platforms, then we'll
talk.
Remember that your XML displayer has to work on a PalmPilot, an
IBM3278 (24x80 text-only monitor) driven by IBM's MVS operating
system (EBCDIC-based, no less), and a DecWriter dot-matrix printer/terminal.
I've personally read ASCII-based RFCs on all those. Oh, and you
have to be able to show value-added - that it does a BETTER job
than ASCII on those 3 devices, as well as everything else
Repeat after me:
Everybody can display ASCII. Until everybody can display XML, we won't
be using XML for the canonical form for RFCs. This is *different* than
what Marshall Rose did in RFC2629 - note that that document is itself
*flat ascii* describing how to write XML and *then convert it to create
a flat ascii RFC*.
Valdis Kletnieks
Operating Systems Analyst
Virginia Tech
Re: Why XML is perferable
Yet maybe we can safely assume that most of the people who are interested in the Internet are, or will be in a short time, familiar with XML documents. where do you get that idea? Absolutely not from IETF maillist. And there're so many internet sites other than www.ietf.org.
Re: Why XML is perferable
Repeat after me: Everybody can display ASCII. Until everybody can display XML, we won't be using XML for the canonical form for RFCs. This is *different* than what Marshall Rose did in RFC2629 - note that that document is itself *flat ascii* describing how to write XML and *then convert it to create a flat ascii RFC*. I feel very sorry that I cannot repeat after you. If following arguments have come forth, I'd like to repeat: One can display doesn't necessarily mean one can comprehend. One cannot comprehend doesn't necessarily justify that one is the very person that should be blamed. // That's the reason why I write this email in flat ASCII, not in XML. // Besides, it doesn't pay to present such a simple message in XML. // Maybe it's also the reason why Marshall Rose wrote RFC2629 in // plain ascii. One may eventually comprehend doesn't mean one comprehends in time. One hasn't comprehended in time doesn't necessarilly justify that one is the very person that should be blamed. // So the presentation format of the idea makes sense. // XML provides significant presentation convenience, besides other merits.
Re: Why XML is perferable
Wang Xianzhu wrote:
to render XML documents to pure text presentation. There will be
^^^
converters from XML to HTML, ms word, ps, pdf and any other types of
presentation, suitable for any type of readers.
Meanwhile I stick with ASCII, which I can grep, cut paste.
Also I don't think it will be at all practical to drive email
discussions
for ietf drafts if we have to start using XML/HTML/SGML/*ML crap.
BTW, there are RFCs (1125, 1129, etc.) only available in ps format, and some
provided both text and ps versions. ASCII text is not enough to describe
information.
Well it worked fine for 2800+ documents and how many today ?
implementations
of tcp/ip protocols running on how many devices ?
I wonder if anyone can write a readable pure text version of ITU-T P.861.
What P.861 {Objective quality measurement of telephone-band (300-3400
Hz)
speech codecs} has to do with tcp/ip and rfc's ???
BTW, I hate to pay for ITU documents what are supposed to be public (I
still
remember the years old discussion when they ceased to exist available
for anon ftp)
Regards
Jorge.
