Re: Why we shouldn' use ASCII text
Alex Kamantauskas wrote: Away with your Mesopotamiacentric alphabets and writing implements!! Intelligent grunting was good enough for mankind for a million years! From certain email lists to which I'm subscribed, it seems that it's still good enough. Oh, you said *intelligent* grunting... sorry ;-) James
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
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: HTML better for small PDAs
-Original Message- From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]] Sent: Friday, February 23, 2001 3:37 AM To: Doug Sauder Cc: [EMAIL PROTECTED] Subject: Re: HTML better for small PDAs 1) Was your millenia-old data *written in XML*, or was it *converted to* XML within the past 5 years? This is not a valid argument. Egyptian Hieroglyphs were not written in ASCII either !
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
HTML vs. TXT: let's compare!
Hello, let's compare: http://dmoz.org/Bookmarks/G/gaelle/RFC/Routing_and_Addressing/BGP/ and http://www.ietf.org/internet-drafts/draft-chen-bgp-reference-01.txt Some fellow perhaps prefers the first one and some others may prefers the second one. Some may take aspirin, and some may eat chicken soup. Why not have both? regards, -- Rahmat M. Samik-Ibrahim - VLSM-TJT - http://rms46.vlsm.org - Don't cry for me, Nusantara;the truth is that I never...
Re: Writing Internet Drafts on a Macintosh
Also, why isn't HTML an accepted format for Internet Drafts just a sec. traditionally, we have this discussion every six months. it has not been six months yet. And the poisson is due to start its five year cycle to discuss about the future format of an RFC. The last consensus (1996) was "let's wait five years :-). regards, -- Rahmat M. Samik-Ibrahim - VLSM-TJT - http://rms46.vlsm.org - Don't cry for me, Nusantara;the truth is that I never...
Re: Writing Internet Drafts on a Macintosh
Stephen McHenry [EMAIL PROTECTED] wrote: Am I the only one that finds a certain bit of irony in the fact that the last IETF conference provided "peek at the future" style networking - i.e., 11MB 802.11 wireless throughout the entire hotel, so that people could literally walk from one end of the hotel to the other with laptop perched in the crook of one arm while using the other to do e-mail, web browsing etc... ...AND that these are the same people with archaic browsers and e-mail clients that can't handle recent advances in technology - even to the point of using "dumb" devices that can only handle ASCII? Not everyone considers a move from ASCII to HTML "an advance in technology". --Johnny
Re: Writing Internet Drafts on a Macintosh
Somewhere in the flood of email on this topic which is filling my inbox, we have lost track of the fact that the IETF does not produce documents only for its own use. The idea is that everyone everywhere should have access to them and the least common denominator is still ASCII. (At least, the practical LCD. I can think of few extra uses for the stone tablets at working group meetings though...) John Stephen McHenry [EMAIL PROTECTED] wrote: Am I the only one that finds a certain bit of irony in the fact that the last IETF conference provided "peek at the future" style networking - i.e., 11MB 802.11 wireless throughout the entire hotel, so that people could literally walk from one end of the hotel to the other with laptop perched in the crook of one arm while using the other to do e-mail, web browsing etc... ...AND that these are the same people with archaic browsers and e-mail clients that can't handle recent advances in technology - even to the point of using "dumb" devices that can only handle ASCII?
Re: was Why we shouldn' use ASCII text (now censorship)
In message [EMAIL PROTECTED], Jon Crowcroft typed: on another topic, we noticed that we cannot see certain sites that provide some interesgint IP anonymizing services -we ran a traceroute -p xyzd to them and discovered that some hi-level ISPs are running some port filtering - interesting - should one peer with such folks given its hard to route around them as an end user? putting out the fire with gasoline... my mistake - it was the egress from a site to an ISP that was admin blocking the port - not an ISP - big error reading output from traceroute -p on my part -sorry: isps, not guilty; crowcroft, guilty. sincerely jon
Re: HTML (was: Writing Internet Drafts on a Macintosh)
Johnny Eriksson wrote: Stephen McHenry [EMAIL PROTECTED] wrote: ...AND that these are the same people with archaic browsers and e-mail clients that can't handle recent advances in technology - even to the point of using "dumb" devices that can only handle ASCII? Not everyone considers a move from ASCII to HTML "an advance in technology". /lurk Think of Radio and TV. TV was an extension of Radio, using technology developed from Radio, not available until engineers had spent a couple of decades pondering Radio improvements, and mostly using parts only available because Radio had created a strong electronics industry. So, TV was "an advance in technology" over Radio. And, of course, TV allowed for improved communication in some ways. It just tends to have a very low signal/noise ratio, making it harder for the user to find any useful data on the boob tube than it is on your radio. It also _requires_ a much more complicated infrastructure to pass a message, more effort from the creater, and more attention from the recipient (two senses - a primary and a secondary - engaged vs. just one secondary sense), so that people who could multitask while listening to the radio can't do anything else while watching TV. Now, TV has it's uses. It's just not very efficient for transferring audio. If you don't _need_ pictures, then you're wasting bandwidth with TV. And there's never enough bandwidth. Which is exactly my objection to HTML vs. ASCII. People post in ASCII because they think they have something useful to say - and it's easy for anyone who wants to get it, read it, store it. People post in HTML because they think they have created something pretty, and want to share it - and the post is not universally viewable, takes time to get and space to store, and is generally pretty but useless. So, you arrive at a simple two-state system: pretty people use HTML, and useful people use ASCII. There are, of course, exceptions, but if you see a post in HTML you already have a strong clue about the writer's value system. lurk -- : Unable to locate coffee. Operator halted.
RE: HTML better for small PDAs
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Thu, 22 Feb 2001 21:01:23 EST, you said: I am not sure I agree with the statement that in 10 years XML will be history. One of XML's greatest values is in the fact that it is a good format for long-term archiving of written material. Some very old material (several millenia old) is available in XML format -- that's more than the 32 years for RFC1. ;-) The reason old text has been converted to XML is not so that people can read it on a GameBoy, but so that it can be archived, indexed, converted to other formats, etc. 1) Was your millenia-old data *written in XML*, or was it *converted to* XML within the past 5 years? Duh!? ;-) Obviously, this is a rhetorical question. 2) Will you be able to find the DTD you need in 2035? Well-formed XML documents still have value even without a DTD. It's usually pretty easy to guess at what the elements mean. If the documents are of value to a lot of people at the time, then yes, you probably will be able to find the DTD and one or more style sheets. If it's just a historical document, then maybe or maybe not. I'll bet that you'd be able to find a plain text rendering of the document, though. An alternative point of view is that in 10 years XML will have achieved a critical mass, so that it becomes as entrenched as many other standards: ASCII, TCP/IP, C, etc. OK.. Wake me up in 2011 and I'll be MORE than happy to reconsider. ;) I don't have a crystal ball, and I have been around long enough to have seen fads come and go. XML seems to me to strike the right balance between simplicity and value-add, so that I would consider it a pretty safe bet for the long-term as a document format. Anyway, I don't expect that the IETF will be moving from plain text to any other format for years, if ever. For the most part, this discussion is academic. Here's a proposal though: how about multipart/alternative! ;-) Seriously, storage is incredibly cheap. Why not store documents in several formats? If the plain text rendering is the normative document, I don't think anyone would have a problem with that. Perhaps the RFC editor could accept documents using the DTD from M Rose as well as the normative plain text format. I'm not suggesting that the editor take on a lot of new work, just that XML documents, when submitted by authors, be made available from the Web. BTW, I have always liked the layout of the RFCs -- namely, that they are nicely paginated with page numbers and headers. On the other hand, HTML often doesn't print very well. -- Doug Sauder
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: HTML better for small PDAs
Just a few final observations, then I'll bug out of the discussion. 1. Some folks scoff at the idea of reading I-Ds and RFCs on a PDA, yet they think it's necessary to accommodate those who would read them on 1950s-style teletypes or other old, outdated equipment. We say that lines should be, what, 76 characters long? Why? What about 40 characters per line? Then I could read the RFCs on my old Commodore 64 in addition to my PDA. ;-) What *is* the lowest common denominator, anyway? 2. RFCs have a limited lifetime. RFC 1 might be 32 years old, but it's probably only relevant to historians. Historians will probably find the tools they need to view old documents. So, if RFCs are maintained in a format that outlives the technology documented in the RFCs, then there's no problem, right? (Speaking from the aspect of archives.) Anyone know how long ASCII will be around? -- Doug Sauder
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: HTML better for small PDAs
On Fri, 23 Feb 2001 10:52:51 GMT, [EMAIL PROTECTED] said: 1) Was your millenia-old data *written in XML*, or was it *converted to* XML within the past 5 years? This is not a valid argument. Egyptian Hieroglyphs were not written in ASCII either ! Actually, it *is* a valid argument - consider that hieroglyphs were unreadable until they found the Rosetta Stone. The media lasted, but the ability to parse didn't. ASCII has proven to be understandable 40 years after being written. XML has proven to be understandable 5 years after being written. Hieroglyphs have proven to be recognizable but not understandable 2000 years after being written (2000 years placing it just BEFORE the Rosetta Stone was found) Now, who was saying that you didn't need a DTD to understand the XML? ;) -- Valdis Kletnieks Operating Systems Analyst Virginia Tech PGP signature
RE: HTML better for small PDAs
The way I think about it, the current "ascii" rule makes it hard for the writer, moderately easy for the reader, and very easy for the archivist. It is hard for the writer now, because we are mostly using wysiwig tools that don't produce ascii very naturally. OTOH, it is not too hard -- for example, the extra cost of postprocessing a Microsoft Words formatted document to an internet-draft format is at most a couple of minutes, which seems a reasonable investment when you write for the posterity. As a matter of fact, it does not take longer than the nroff postprocessing that we used when nroff was the norm. Ascii text is moderately easy for the reader. Let's face it, the 72 character per line format has its roots in a time of 24x80 character screens, which itself had its root in the generic 80 columns punch card. That is fine when a screen is large enough to display a full line of text, but that is definitely suboptimal on small screens. A marked-up presentation would allow for better rendition on small PDA screens, and would also allow for a better support of those of us who have a poor eyesight. OTOH, the RFC format is very regular, with fixed size pages, regular indentation, etc. Many people have already written filters that convert this format into their preferred mark-up language, which is a reasonable compromise for viewers. We should note that the "ease of view" argument is an argument for mark-up languages, not for fancy page formatting languages such as Adobe's PDF: if you cannot reformat the page on display, there is no particular benefit for the owners of small screens or weak eyes. But the very benefits that make make marked-up presentation tempting also carry a big risk in a standard world: if the documents you view depend on how you view them, there is a risk that conficting view generate conficting interpretation. That risk is well known in international circles, when for example the translation of various UN resolutions can carry slightly different meanings in different languages. If we want standards, we want a simple reference. Printing an ascii text with a fixed font and a fixed page set-up gives us that. In my opinion, the hardship imposed on the authors and on the present readers is more than compensated by the ease of archival of the text format, the ease of read by future readers, and the adaptation to the job at hand, publishing standards. Mark-up languages have evolved in time, from nroff to tex and latex, from wordperfect to office XP, from sgml to html and xml. Markup languages tend to be highly parametrized, with various nroff or tex macros, various word templates, various html extensions and xml dtds. The macros tend to have an even shorter lifespan that the languages themselves, which make them even poorer candidates for an archival function. Frankly, the energy spent every fice years in questioning the ascii format would be better spent in writing transition tools... -- Christian Huitema
Re: HTML better for small PDAs
Actually, it *is* a valid argument - consider that hieroglyphs were unreadable until they found the Rosetta Stone. The media lasted, but the ability to parse didn't. If we're going to stray onto the treacherous ice of logic here, then I feel constrained to point out that ASCII, XML, and so on are merely ways of formatting characters, not languages in and of themselves. The clay tablet vs paper comparison really isn't applicable either, because the basic storage and display media do not change in our example, regardless of which format we adopt. A more precise analogy would be something along the lines of 'shall we use ink, paint, chisels, or chalk?' I'm afraid that even this construct isn't particularly useful in our context. There are times when analogies can shine a bright light on a dark debate, but they may also be the last refuge of the obfuscator. I say ASCII source documents are fine; if someone wants to convert their personal copies of the docs into XML, PDF, HTML, or Morse Code, they're perfectly welcome to do so. Cheers, RGF Robert G. Ferrell, CISSP Who goeth without humor goeth unarmed.
Re: Writing Internet Drafts on a Macintosh
From: Keith Moore [EMAIL PROTECTED] Date: Thu, 22 Feb 2001 14:41:30 -0500 AND that these are the same people with archaic browsers and e-mail clients that can't handle recent advances in technology - even to the point of using "dumb" devices that can only handle ASCII? I doubt that any of those laptops could handle only ASCII. But the fact is, many experts prefer the power and flexibility of a text-based interface for many tasks, over what you call "recent advances in technology" that involve "smart" devices, mice, and bitmapped displays. One of the great, heralded "advances" which Microsoft touts in Windows 2000 is that all administrative interfaces are scriptable --- which means in practice that it's possible make all administrative changes from the command line (so it can be scripted using a batch file), instead of forcing people to use the GUI control panel. So it's official. Microsoft invented the command-line interface; isn't great how they use their freedom to innovate? :-) - Ted
Re: HTML better for small PDAs
On Fri, 23 Feb 2001 13:22:15 EST, Jeremy Foshee said: Valdis wrote: Now, who was saying that you didn't need a DTD to understand the XML? ;) You don't. XML has the ability to stand on it's own if you desire. Umm.. without a DTD, how do you interpret all the markup that was the POINT of using XML? Yes, a XML document without the DTD can be syntax-checked, but let's think for a moment - if you don't have the (hypothetical) rfc2119 DTD, what is the *semantics* of: pointImplementors of Turbo-Foobar shouldsupport the XYZ extension/should /point Before you say "but we all know what 'should' means", consider that we felt it necessary to publish RFC2119. -- Valdis Kletnieks Operating Systems Analyst Virginia Tech PGP signature
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
HTML same problem with TXT. XML/SGML the solution
I say ASCII source documents are fine; if someone wants to convert their personal copies of the docs into XML, PDF, HTML, or Morse Code, they're perfectly welcome to do so. ASCII source documents are not suitable for convertion. This is also true for HTML and pdf files. If I convert a document, I need to know the logical structure of the document. ASCII documents lack these meta information. Although HTML and pdf files have information about structure, but this information is only for presentation, not the logical information of the document. All these formats of documents are for presentation, not for manipulating. Mixing up the manipulating and presentation processes has many problems. XML/SGML is the solution. Regards, Wang Xianzhu Cheers, RGF Robert G. Ferrell, CISSP Who goeth without humor goeth unarmed.
