Slashdot Mirror
Why XML Doesn't Suck
Richard Eriksson writes "Recalling the earlier discussion on why XML sucks for programmers, Tim Bray clarifies his stance on his co-creation, XML, and gets back on his pulpit to declare that XML Doesn't Suck. He writes: 'Let's look at some of XML's chief virtues, then I'll address some of the XML-sucks arguments, in the same spirit that Sammy Sosa addresses a fastball.'"
Just my 2 cents.
today is spelling optional day.
These days we have zillions of XML parsers to play with, and they make it pretty darn easy. And it sure is nice to know that when a vendor says they'll give you XML, you can read it. Unless that vendor is Microsoft, of course.
Mr. Bray makes a point about the longevity of XML based documents (where he says that tying up documents in a binary format is foolish), but this is a point that (La)TeX users have been arguing for years.
Will XML really solve this problem? Hopefully the OpenOffice format will help, but if Microsoft maintains its marketshare (and keeps its XML generation limited or even proprietary), are we really better off?
I'll just stick with LaTeX.
I havn't read the article yet, but XML does NOT suck because:
1. the data and/or fields added at anytime WITHOUT breaking anything
2. the data is in a heiracherical format, reducing data replication and allowing for a more sophisticated data structure.
3. the daya can be changed by a text editor.
4. and BECAUSE the data is text, it compresses REALLY well.
I don't get all this fuss over XML. It seems to me that it's just a pretty handy markup language for programmers to use to store data in a human-readable (and therefore human-editable) fashion, that (with the help of things like libxml) also happens to be fairly machine readable. It's also extensible (X- duh!) and yet also has its limits.
/. stories about this? Can somebody explain why this raises people's passions so? It seems to me like arguing the merits of HTML or SGML - it's all so bloody obvious!
Why are there so many
As a web developer & admin, XML is my best friend. I have cases where I need non-webheads to develop content (better yet, portable content), and XML is the only way - they only have to know a basic set of HTML tags, they don't have to worry about HTML validation, formatting, or anything else, and everything they generate is consistent!
Not ony can I transform their content into different views or formats, but (for example) the same XML file that is used to provide software documentation also is used to build the software GUI and provide tool tips and other forms of context sensitive help.
No database required. No parsing required. Just a couple libraries and tools, and we're set to go.
I saw a letter to Dr. Dobbs recently that was saying that XML needed to have the ability to embed things like Visual Basic and javascript in it to be really useful. I think that this is a horrible idea. The whole point of XML was to have a generic data model, i.e. one parser to rule them all.
I've been able to do thing like export MySQL schemas into XML, then using XSLT generate an entire set of base classes providing persistent objects. What was once weeks worth of work, now takes an afternoon (from concept to final product). The whole set is entirely consistent, no misspelled names or changed signatures. When bugs were found, I fixed all the files in one place and rerun the XML/XSLT script. Massive productivity boost. If that isn't an argument on why XML doesn't suck I don't know what is.
The idea of embedding code in XML is a perverse distortion of what XML is really about. XML would suck if one uses it for unintended purposes. I don't use a hammer to tighten machine bolts, well I guess some people do.
I used to wonder what was so holy about a silent night, now I have a child.
poking around his site I came across this. hehe.
/., and by following back the links in from other blogs, I sure did learn a whole bunch about the state of the programming art as regards XML. Some of the things I said were wrong (or at least open to challenge), and I got fodder for a really substantial follow-up piece, which I'll get around to soon. I don't suppose it's mathematically possible for everyone to get their theses batted around by some tens of thousands of well-informed people, which is a real pity."
1 9/ Who
"Slashdot and Stupidity I visit Slashdot once per day, sometimes more, because they seem to do a really good job of relaying the geek zeitgeist. It's a long time since I read much of the follow-ups, but I thought I ought to this time, and I'm reminded why. How can a publication that caters (on the face of it) to smart people attract the attention of so many shallow, drivelling morons?"
"Interactivity Again There were a few smart things there in among the chaff on
http://www.tbray.org/ongoing/When/200x/2003/03/
XPP which has evolved into Common API for XML Pull Parsing . I don't believe there is a standard pull-based API for XML parsing in the Java world yet although there is JSR 173.
I work for a VAN (Value Added Network) which is basically a middleman for data. You send an electronic purchase order to us; the company you're ordering from gets it from us. The value we add is we'll say you sent and tell you they got it.
However, we charge by the kilocharacter of data you send and receive per month. So, for us, XML is awesome, because it increases the size of an ASCII-X12 or EDIFACT document by a factor of 5-a lot more (usually somewhere around 15-20 I think).
X12 and EDIFACT are standards for business document exchange that have been around for a while, but people are converting to XML because they think it's better (eventhough, usually, they just use the X12 or EDIFACT format, but with XML tags).
For example, a line item record may go from something like this:
LIN:0001
to something like this:
<LIN_GROUP>
<LIN>
<LIN_01>0001</LIN_01>
</LIN>
</LIN_GROUP>
It's not always that bad, but it can also be much worse. (Imagine replacing each instance of "LIN" above with "Line_Item" and "LIN_01" with "Line_Item_Number".) (And why won't that semi-colon after the LIN_01 end tag go away?)
so-- for us, XML doesn't suck-- it increases our revenue. For our clients, it's sucks, because it increases their monthly bill.
Just make </> close whatever the last tag was. That instantly cuts the size of the files in almost half, and makes them easier to read as well.
And yes, it could be confusing in a heavily nested file, but nothing says you have to use them. It would be a godsend for database columns.
Sometimes it's best to just let stupid people be stupid.
It has been my observation that much of 'XML' work with the query engine extension has been a recreation of hierarchical databases. But relational databases were designed to overcome hierarchical databases' failures. It seems we are turning back the clock. For a good critique of XML, C. J. Date's site has an article critical of XML http://www.firstsql.com/dbdebunk/
putting the 'B' in LGBTQ+
Two words:
Human-readable.
As a programmer, this is the most useful property a data stream can take on. Why? Debugging. The reasoning here is twofold:
1. Non-parallel development of opposite ends of the data stream:
It's quite a challenge to develop the code which produces the data and the code which uses the data at the same time. If it doesn't work, you don't know where the problem is. With a human-readable format, you can simply pipe the data in or out of the app directly from a text file, and verify that it's correct yourself.
2. Debugging:
Something of an extention of the previous, if you have two bits of code communicating through XML, you can log the bad transmission and read it yourself to find out if the bug is in transmission or reception.
Now, I won't pretend that XML is the only human-readable data-structuring format, but it has a lot of nice advantages over the others, each of which is covered in the article. XML makes apps a pain to develop, but a breeze to debug--and the debugging is far more important!
-Amalcon
Let's say you are using XML to store the class rosters for your school. Assume the structure, . This has the advantages of being the easiest to parse, you create your data-structure and it's finished, and lastly, writing XSLT to convert your XML to HTML is a piece of cake. However, it's both redundant in the XML itself and in memory.
Assuming something more efficient, like <class><studentId>, where you simply reference students by an id rather than inlining each student's data, removes the reduplication problem. However, everything else becomes harder. First, you have to be able to reference a student by its id, so you use a hashtable. Next you either have to require that student data comes first, or you have an update phase where you update each of your class objects. Lastly, XSLT isn't cake anymore (show me the roster for class X including all the students details).
Although this problem exists in any other application that parses data that contains internal references, it's still a major pain-in-the-ass.
What's the best way to tackle this situation?
... Like most of folks here, we've successfully used it in several situations, across different languages (Java, Perl, ASP) and different purposes(configuration, data transfer, web page generation, small online data storage, etc). It's da bomb.
XSL/XSLT on the other hand can be a pain to use in anything other than trivial transforms, in my unschooled opinion. The concept of recursive processing is great, but the math/logic syntax available is byzantine (eg "variable" is really a constant).
*sigh* I know this will get modded offtopic, but seriously... anyone agree with me, or do you actually like writing transform logic and processing in XSL? Please comment.
That said, the challenge stems from MV-fields. Those nifty things in PICK which give you the power of keeping associated fields within one table, with as many associations as you like. (for good or for bad, bad usually when it's been abused or good housekeeping neglected.) Piling MV stuff into CSV is just plain icky. Normalizing it first is also icky. However XML may offer a simple, elegant way of keeping it all together in the shape it existed in (which may be important down the road if someone has to produce a report from it (auditors, second guessers, or a55-covering because some account didn't have the right amount of debits or credits for years and the difference needs to be found.)
I'm off to explore XML more fully. There's probably yet-another O'Reilly book in my future...
A feeling of having made the same mistake before: Deja Foobar
It's a good question. We spent a *long* time working with structured data formats like S-exprs between 1991-1997, and although these do support the basic technique of abstracting your way up the expression ladder, XML adds a few small but highly significant things. Some of these are intangible: general acceptance as a standard. Some of them are more concrete: solid support for non-USA languages. Some of them are incidental: wide availability of parsers in any language. Some of them are subtle: essential simplicity.
There is something about lowering the barrier to a point where virtuous feedback becomes not only possible with effort, but easier than anything else. I think this is what XML does to abstraction, more than S-exprs, SGML or any of the many other formal/semi-formal structured data languages that existed before.
Sig for sale or rent. One previous user. Inquire within.
XML forces you to commit to one specific view of your data.
This is why XML serves best as an interchange format, where files are immutable snapshots of more complex data sets. Perfect for EDI-type apps or reports, but not for "live" data.
I know from experience with MCAD files (Pro/E, etc.) that static snapshot-type files are much easier to generate and work with than "live" files (files that are modified, stored, modified again, stored, ad nauseum). This is because data that changes over time has to stand up to such wear and tear without wearing out (i.e., the data model has to be outstanding and elegant), but snapshot data models can be pretty crappy and still get the point across.
Basically, my point is that 1) I agree with what you said and 2) XML does nothing to avoid the fundamental difficulties people already cope with in every data format ever invented (i.e., data models are hard and people should just live with that fact and stop whining).
Healthcare article at Kuro5hin
Some people here say that XML is just a buzzword with no real advantages etc. Let me tell you, they are all wrong.
My company makes apps for the military. These type of apps make heavy use of binary messages exchanged over a network. Up until now, there were numerous errors in the specification, different type systems and other problems between departments. With XML, we managed to do the following:
1) make a standard for expressing messages. Since messages are tree structures (struct embedded in struct etc), XML is ideal for it.
2) made a tool to write messages and group them according to context. Now specification docs can be automatically produced by the tool and handed over to subcontractors, whereas previously they were written by hand, contained many errors and had different styles. Now all these problems are gone, changes are documented and saved in the configuration and versioning/control system, messages are automatically versioned and the whole procedure is automated to the point that it takes a few clicks to modify a message and produce a new specification.
3) made tools which can prepare scenarios for testing these messages automatically. This saved us a lot work!!! it is quite a big amount to test every field of every struct of each message from the up to 10000 message a combat system has (and each message can contain hundrends of numeric fields)!!! thanks to XML, each field's bit width, range, default value, minimum and maximum value and enumeration is known beforehand from the XML data produced for the specification, so by using XSLT messages are automatically converted to C, C++, ADA and Java code along with the relevant code to send, receive and validate each message.
One of the true benefits of XML is that data are not tied to a specific application. For my company, it has saved us a lot of work, because there is no need to bloat one app with all the functionality, we can make several separate tools which do one job only and operate on those XML data.