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.'"
It seems to work well for Apple. It works great for the core database for iTunes, iPhoto and many other apps :-)
Steve likes it, he really likes it!
Actually its doing a 180.
It is doing a 360
Going around in circles yet ending up where you started? I think you mean 180.
We're going to turn this team around 360 degrees.
- Jason Kidd, upon his drafting to the Dallas Mavericks
That sounds like the Mavs., going around in circles but never really going anywhere.
- Me.
Well, then anyway, they're not all that bad at the moment, best motion offense in the league.
The main thesis of Tim Bray's original post was that he didn't like having to choose between either storing all his data in memory (i.e. DOM) or using a callbacks(i.e. SAX) when processing XML. The problem with this kind of thinking is that although it may have been true two or three years ago that the only way to process XML was via DOM or SAX this is no longer the case.
.NET Framework. Similar APIs exist in the Java world as well as Python from what I've heard. This is besides the current push in some quarters for programming languages that natively process XML (i.e. intrinsicly understand an XML datamodel or datatype).
.NET Framework. This article on XML.com points to other people who also point out that such pull-based APIs for processing XML are available on other platforms and languages as well.
There are more classes of APIs supported on multiple platforms for processing XML such as pull-based APIs and cursor based APIs which are represented by the System.Xml.XmlReader and System.Xml.XPath.XPathNavigator in the
Tim Bray's original problem was that he doesn't have a pull-based API for XML parsing in Perl. I pointed out in my kuro5hin diary how the pseudo code he showed as being his ideal for processing XML already exists in C# and
I agree with another poster, your problem is the microsoft tools for reading xml. You're not alone with this problem, a friend of mine was whining just last night about how he hates xml because it keeps crashing his computer. Turns out he was trying to read a 200+MB file with MSIE. BAD idea, microsofts implementation is very bad.
I highly recommend the IBM alphaworks toolkit (cerces or xerces or something). I use this extensively and it works perfectly, without any noticeable memory leaks.
My only issue with XML is that for some reason people think "we should convert our computers and networks to an xml based paradigm" is a sentence that makes sense.
XML is just a nice way of organizing certain kinds of data that's relatively easy to program with. That's about it.
There are shortcomings to XML, certainly. Having worked with it, I know that I've had someissues. But the benefits that it brings (the human readability, the structure, and the parsers that are available for it, etc.), makes it a good thing much more so than a bad thing.
Programming for XML is more work, but in the end, it forces you to be more structured and disciplined to work with it. You are always working with standard way of constructing data and messages, rather than having to reinvent a new wheel each time, or create your own format that is totally different from everyone else's. It's more work upfront, but for maintainability and as Tim Bray points out, longevity, you can't beat it. They don't called it the new ASCII for nothing (though not completely appropro). Just like there were text editors that can open and edit any plaintext ASCII files, so it is with XML files - if you have an XML editor/parser (and they are almost everywhere, including the humble text editors), you can view it and edit it.
It's like following coding standards - it's more pain and effort to do it and to do it right, but you will be thankful for it later, and it will be well worth the effort. Those who don't think it's worth the effort probably aren't building anything that is supposed to last for years to come.
If someone is passing you on the right, you are an asshole for driving in the wrong lane.
Badger
It never ceases to amaze me how many people think XML is a language.
/. should link to a XML FAQ each time they do a story.
LOL, so true. Maybe
XML document == data in a well defined format
XSL/XSLT == tells how to display XML data(think FOP), but is itself a valid XML document
XPATH == XML query language, which after you look a few examples it isn't too hard
SVG == vector graphic format stored in an XML data stream
XML itself is not hard, but until you figure out how all the many pieces fit together it can be confusing. Another thing to keep in mind is that you don't have to use every piece to make use of XML.
The power of XML comes not out of its syntax but out of the tools that are there for it and what you can do with them.
The nice (if obvious) tool for XML is the parser. XML is specified so that any computer science undergrad could write one in a couple weeks. As a result, there are a lot of parsers out there and they all do the same thing. This makes XML easily read by machines as well as humans.
The limitation of XML that you will probably next notice that it does not assign any meaning to data. The same data could be structured in many different ways in a document. For example if you were to describe a zoo in XML, one developer would have animal tags nested within species tags nested within cage tags nested within area tags nested within a zoo tag. Another developer would just have animal tags nested within a zoo tag.
The beauty if XML is that both of the two developers above should have written a specification for the way they did it. Given this specification (in a standard form) you would be able to take a zoo file and verify (automatically) that it matches this specification. (Doesn't have any stray snackbar tags hanging off a lion).
Furthermore there are conversion tools that can convert between the tags used by one developer and tags used by the other developer. The name of this tool is XSLT and you can write transformation instructions that do a lot of work in just a couple lines.
After I knew about these few tools, I started to see why so many developers were excited about XML. There are lots of XML tools out there that I don't know about. I'm sure there are several that I could get even more exited about.
Are you smoking crack? I hate Microsoft as much as the next guy, but have you seen
Granted, MS hasn't backported everything to XML (think we'll ever see an XML registry?) but everything going forward has XML tattooed all over it. I happen to love XML, but if anything Microsoft tends toward the zealous side.
XML isn't a language. It is a metalanguage. It is vague by design, to allow arbitrary languages to be created.
XML is not a programming panacea. It is for structured data.
Suck it up.
Ppppppht! *sprays water all over monitor* Microsoft's not "implementing it?" What in the heck do you mean by that? Have you taken a look at anything in the .NET suite lately? The entire system is built on XML. The solution files, project files, assembly manifests, application configuration files, setup binding files - they're all XML! Visual Studio .NET is build extensively on XML, and the .NET API includes some very intuitive and powerful classes for reading, manipulating, and building XML documents. I suggest you do at least a cursory investigation before spouting something so outrageously inaccurate next time.
Like woodworking? Build your own picture frames.
In the last five years, XML has - for instance - completely revolutionized the way my company writes software. We use code generators that mungle XML definitions into templates (imagine PHP controlling the generation not of HTML but of C or... PHP, and using XML to specify the abstract model in question).
We don't need schemas, stylesheets, xpaths,... just simple XML. And yet we can write very rich code in XML instead of in native code. Today we're producing about 25 lines of final code for 1 line of XML, and we're pushing this up all the time. My current project generates workflow engines from XML definitions, building a 10k workflow application from a single 500-line XML file.
My point is that XML is not just a handy way to store data. It is a meta language, able to formally define any concept, no matter how abstract. This is an incredible but subtle thing. The power comes not from XML technology itself, which is really very, very simple once you ignore the W3C fluff. The power comes from the freedom that XML technology gives you, namely the ability to abstract your problem to as high a level as your mind can take it, and to solve it at that level.
This is difficult, and takes time, but as the XML space settles down it will become clear that this is the real value of the technology.
The 'con' arguments all appear to be related to people trying to use XML in the wrong place, for the wrong thing, or to replace existing abstractions that work perfectly well.
Sig for sale or rent. One previous user. Inquire within.
To me your structure is wrong. When designing an XML layout you really have to think through all possible use-cases.
... and so on
Assuming that there would be many attributes attached to students, and the classes for a given student are likely to change, I would go:
abcde
and other personal fixed stuff
bio101
and repeat the class tag for every
class the student is in
more students like above
You then have a separate XML file of classes
Warshawsky (or use an ID here and have a separate XML file of instructors)
_
_
_
You then "join" the different files in the transform to pull out specifics. It's very much like SQL joins from among normalized tables.
If the above seems very difficult, you probably need a good book. I found "The XML Bible" to be useful when I was learning this stuff.
A language is the set of all ways a grammar allows symbols to be combined.
(of course, a grammar is a set of rules on how to combine symbols.)
Under the formal definition, XML is indeed a language. It is not a language useful for defining algorithms, admittedly.
Can we stop with this "XML is not a language" now?
But bureaucrats being what they are (and bureaucrats being in charge of environmental agencies), they've been told that XML is a GOOD THING, and want to force everything into that mold. And it doesn't fit!
Call it the "law of the instrument," as someone (Poul Anderson, I think, put it:
That's XML, to a tee!"My opinions are my own, and I've got *lots* of them!"
XML schema has far greater capabilities in this regard than DTD's.
I certainly agree that 3rd normal form schemas have advantages above even this. The only problem is that RDBMS schemas are tightly coupled to the individual database application that uses them and can't really exist without, well, an RDBMS. Both properties hamper system integration issues.
You might examine Oracle 9iR2's XML database capabilities, by the way.