i fail to see how this distinction has any importance to the original point. the user wants the words free of markup.
[snip]
if we give the original poster a unicode-aware text-editor, and a file that contains no heavy markup, he will be happy. he wants the words, all the words, and nothing but the words.
[snip]
ok, and now here you seem to be trying to say that an x.m.l. file is a plain-text file. it's not. it might consist of nothing more than
You spelled XML incorrectly again.
again, this subterfuge is dishonest.
first, it's inaccurate to say that an x.m.l. file is "human readable". and second, it's misleading to say it is "a type of plain text". it might be an ascii file, but it's decidedly _not_ "plain-text".
Are graphical buttons that contain letters "human readable"? What about product labels? Billboard signs? None of those are "human readable" (at least in the capacity that say... an OCR application could be able to decipher their meaning).
let's give the original poster an x.m.l. file, and have _him_ say whether he is able to "read it".
Sure, you can read the XML file with a browser, if you have the appropriate stylesheet that goes with it. A text editor does nothing more than "render" the text to the user's screen. Markup is the semantic instructions that describe exactly how that text is going to be rendered. A "text editor" that understands XML can easily make those tags invisible to the end user, or fold the sections, etc. This is all just a silly argument, and by your definition, your own wacky ZML format is not human readable either. What exactly is your point with this diatribe anyway? You're not going to save the world from XML, and you're certainly not going to convince others here who use it in their daily jobs. So what exactly is your point?
just because you can load a file into a text-editor doesn't mean you'll actually be able to figure out _how_ to edit the darn thing in the way you want.
First it was about giving a 'user' the XML file to read, and now it's about editing the file? Which is it? If you're trying to edit the file, you should be expected to have the necessary tools and skills to do so. "Users" shouldn't be expected to build software on their machines without the proper development tools and environment set up to do so. Which brings me to another point: Is source code "human readable"? Its marked up in a way that provides instructions to the user's editor and compiler. By your definition, it too can't be considered "human readable" unless we remove those instructions. Removing them however... fundamentally changes how the "text file" is handled by the reader. And also by your definition, since an XML file is not "human readable", it must fail the test for GPL compliance. How would you provide a person with the "human readable" format of the source, to remain in compliance with that license? Would you consider XML the "machine readable" source instead?
these semantic games do nothing but cloud the discussion.
By trying to assert that XML isn't plain text, you are the one confusing the issue. Since < and > are within the 0-127 character limit, XML is actually ascii text. That means it is "plain text". You lose this argument based on your own conclusions.
the inference you are trying to get us to make is that "cleaning out all the tags" will convert an x.m.l. file into a plain-text file, magically. it won't.
It won't, because it already is a "plain-text" file. Cleaning them out just removes some of the plain text, leaving other plain text behind. There is nothing different from removing <this> and <that> from the text, just like removing (this) and (that) from the text.
i've been writing a separate post that will give details how this careful consideration and crafting must be done. (some hints: whitespace, quotemarks, and tables.)
Does it pass an XML validator? Is it well-formed? If not, then it isn't XML, and it is some other plain-text format with whitespace, quotemarks and tables.
pay attention to this, lurkers! it's a sure sign of vapor-ware!
What is the vaporware? I haven't seen it yet. XML exists, its not vaporware. I use it quite heavily to store Palm records with pilot-link. Its a great medium for atomic, record-level data in that specific case. But I'm seeing that your argument is full of hot air... or vapor, if you wish to use proper semantics. ;)
in its day, s.g.m.l. made all the same promises as x.m.l. does now. it couldn't keep them, so s.g.m.l. people had to invent a variant, so they could regenerate all their hype from scratch and reuse it.
No, SGML is completely different in goal and purpose from XML.
and sure enough, the public is gullible enough to believe it all again.
When you believe the hype that XML has anything at all to do with the "Web", then you're the gullible one. XML is an empty bucket, nothing more. It simply "holds". That's it. This whole "XML is the future of the web" business is all just hype pushed by companies trying to sell you products based on XML that intersect with the web.
of course, the same difficulties that thwarted s.g.m.l. back in the day -- sabotaging all their hype -- will return and bite x.m.l. in the butt.
You're spelling SGML and XML incorrectly again. For someone who is trying to defend what is, and what is not "plain text" or "ascii" or "unicode", you certainly don't know how to use grammar and spelling correctly. You would add significant weight to your arguments if you were able to articulate them using proper English.
they'll "know about" that x.m.l. version indirectly; it will be the reason their books are so expensive. due to all that cash those consultants carted away.
Excuse me? How does storing a textual work in XML in any way increase its price? In fact, it should dramatically decrease the "price", because it requires less handling to convert to any of a dozen or more formats. Having to recreate a work in Word, pdf, XML, text, and so on is much more "interactive" work if your base format is something other than XML. It requires much more "carbon-based" handling to maintain in those formats (not to mention additional storage and processing and maintenance at update time).
XML is only a long term and safe archive format
hype and marketing.
And your solution is what? Your wacky ZML answer? Please.
you can save a spreadsheet in "plain-text" form too, and then "use any software for processing" that too. but you're going to find yourself coming up short.
Not by your definition of "plain text".
likewise when working with an x.m.l. file in a plain-text editor; yes, it can be done, but you will find yourself coming up short.
Funny, not a single anti-XML argument I've ever read (and I've read hundreds) has ever said "XML is hard to work with because its not plain text". Except here of course.
but x.m.l. people will continue telling us this untruth, because they want us to believe that x.m.l. is really simple. but it's not.
Because you're the only one who doesn't seem to grasp the means by which XML can be used, edited and converted, does not mean the format suffers or is lacking in any way. The "X" in XML stands for Extensible. So extend it to suit your needs, or use something else. Nobody is twisting your arm.
of course, if it ain't human-readable in that form, it doesn't really matter if it "will never be lost".
Right, since XML is plain and simple and human readable, the documents contents will never be lost or buried in an unparsable format or a format that requires specialized tools to edit or maintain.
i will repeat: make x.m.l. work if you want us to respect it. don't come and _tell_ us how wonderful it will be; show us. the proof is in the pudding. not in the hype and marketing.
Have you ever read an XML file that is properly styled, in an editor that properly renders it with that styling intact? XML was not meant to be "read" by human eyes. Its a bucket, it "holds". You process it to turn it into something that can be read by humans or other machines or whatever. It is "source code" in that respect, to the "compiler" (XSLT, DOM, parsers) that is used to read it. And as much as I hate to bring it up, how many times have you openly exclaimed that you were leaving for good, and failed to do so? More hype and marketing? David A. Desrosiers desrod@gnu-designs.com http://gnu-designs.com