Slashdot Mirror
The Future of XML
An anonymous reader writes "How will you use XML in years to come? The wheels of progress turn slowly, but turn they do. The outline of XML's future is becoming clear. The exact timeline is a tad uncertain, but where XML is going isn't. XML's future lies with the Web, and more specifically with Web publishing. 'Word processors, spreadsheets, games, diagramming tools, and more are all migrating into the browser. This trend will only accelerate in the coming year as local storage in Web browsers makes it increasingly possible to work offline. But XML is still firmly grounded in Web 1.0 publishing, and that's still very important.'"
Sparingly. JSON is just plain better, and doesn't inflict an enterprisey mindset on anyone that tries to use it.
I don't get it. We can argue the merits of data exchange formats 'till we're blue in the face; yet I cannot see why XML is so popular. For the majority of applications that use it, it's overboard. Yes, it's easier on the eye, but ultimately how often do you have to play with the XML your CAD software uses?
I'm a programmer, just like the rest of you here, so I'm quite used to having to write a parser here or there, or fixing an issue or two in an ant script. The thing that puzzles me, is why it's used so much on the web. XML is bulky, and when designed badly it can be far too complex; this all adds to bandwidth and processing on the client (think AJAX), so I'm not seeing why anyone would want to use it. Formats like JSON are just as usable, and not to mention more lightweight. Where's the gain?
ilovegeorgebush
It seems to me to be a slight improvement on ini files, csv and the like. But parsing it is hideously inefficient compared to a binary format. It's bloated too, so it takes more time to send it over the net or save it to disk. I've seen some XML schema that are aggressively hard to read too. And yet it's become something that every new technology, protocol or applications needs to namecheck.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
I'm not saying that XML is the end all be all, but if your application blows up because someone fed it bad data in XML, your program is broken, and no data format is going to fix it. As the developer, it is your responsibility to vet the data before trying to use it.
Too bad I used up all my mod points earlier...this post deserves a +1 Insightful.
I was just a neophyte developer when XML first surfaced in buzzword bingo, but it was the beginning of my realization of how to recognize a "Kool-aid" technology: if the people who espouse a technology can not give you a simple explanation of what it is and why it's good, they are probably "drinking the "Kool-aid".
Unfortunately, I also have since discovered the unsettling corollary: you will have it forced down your throat anyway.
Momentarily, the need for the construction of new light will no longer exist.
To pick just a few of your actual points...Why on earth would you use a separate thread. SAX callbacks allow you ample opportunity to maintain whatever state you need and DOM parsers cache the entire thing into a hierarchy that you can navigate to avoid having to maintain any state of your own. Granted, the uses for DOM parsers are few and far between, but SAX parsers are quite simple to write, don't require an extra thread and can be done on-the-fly to avoid having to load the entire document at any time. I'm not sure how you get "primitive and difficult to work with" since it rarely takes me more than a few minutes to write a SAX parser, and XML binding technologies (e.g. JAXB, Castor, etc) make it even easier.That's entirely incorrect. See the following snippet:
<element name="myelement">
<simpleType>
<restriction base="token">
<maxLength value="20"/>
<minLength value="1"/>
</restriction>
</simpleType>
</element>
Somewhat verbose, yes. But it's not particularly difficult to learn the syntax. And then a value that's not within the expected bounds will now result in a validation error.If you apply an XSD validation, and your XSD is somewhat complete, you can be pretty sure that anything that makes it past the parser will be of acceptable length or even has an acceptable value (in the case of enumerations and unique constraints). This is all pretty simple stuff and it's not difficult to do. Compare this with writing your own parser where you have to do all validation of the format yourself. How is that easier again?When was the last time you tried it, 1995? Nowadays, compression algorithms require so little processing power that XML adds only a minimal amount of overhead when transfered over the wire.Quite frankly, your position makes about as much sense to me as the people who advocate using XML for everything (XSL-T creators, I'm looking in your direction). XML is a tool, and a useful one at that. In some situations it's very helpful and in others it's not. It's not hard to tell the difference. If you need hierarchically-structured data that's easy to parse, XML is great. It's simple to write parsers and the available toolset handles a lot of what you'd otherwise have to do manually.
I'm actually curious what an XML-luddite like yourself would advocate instead. Give me an example of another technology that allows me to represent hierarchical data, have a standardized validation format so I can allow others to create data in a format I specify and uses an existing parser that takes me almost no time to integrate with. What would you recommend I use when presented with this all-to-common scenario?
Cheers, Qbertino. This is the best explanation of XML's raison d'etre I have ever heard.
I think what people might hate most is DTDs. That makes sense. Even their creator says they suck. There are many ways around them... Lisp can be one big full-service XML processor. Easily. With happy ending and no need for the DOM or SAX.
The bottom line is, XML is nothing (literally) until you spec YourML. And most people don't have a need for that! So it seems useless to them. If you are writing markup languages for application spaces that don't have them it's a godsend. And it is leading to improvements and much-needed standardization.
I've never understood why seemingly rational people whine about XML. It's like whining about mathematics. They're like that for a reason; their intrinsic structure provides their utility. It's not some arbitrary syntax decision that you can whine about. Don't like how modulo works or the concept of recursion? It's AXIOMATIC, baby. Don't like close tags? They're there for a reason.
As for a SQL replacement... have you checked out Berkeley DB XML? Have you found anything promising that you like?