Summary
In a recent IBM developerWorks article, Elliotte Rusty Harold ponders the future of XML.
Advertisement
While XML stands for the last letter in AJAX, the fashionable buzzword of the day, few Ajax application developers actually use XML, observes Elliotte Rusty Harold in a recent IBM developerWorks essay on The future of XML: How will you use XML in years to come?:
Although the rebels sail under the Asynchronous JavaScript + XML (Ajax) banner, and although the x in Ajax stands for XML, no one uses XML much for any of this. Almost as soon as the acronym was coined, Web developers began replacing XML with raw JavaScript code and passing it around as data, and then executing it with eval() —security issues be damned.
Harold notes that XML per se is not the problem. Rather, the problem is the most popular API that emerged around XML, DOM:
The problem is one of APIs, not data formats. More specifically, it's a problem with one API: Document Object Model (DOM). Most developers learn DOM first and then never learn any of the alternatives. They don't distinguish between DOM and XML, and thus they confuse their well-founded disgust with DOM with an unfounded disgust with XML...
DOM isn't a least-common-denominator API: it's a worst-common-denominator API. You couldn't design a worse API for processing XML if you tried. But developers are extremely resistant to learning new things. Outside the Java community, where JDOM and dom4j have made some progress, better alternatives like E4X and the Amara XML Toolkit remain almost unknown and are actively resisted...
DOM is a millstone around XML's neck. It's the single biggest impediment to broader XML adoption in software development. XML has gone as far as it can in programming while dragging this 2,000-pound boat anchor behind it. Unless the World Wide Web Consortium (W3C) and browser vendors deprecate DOM and replace it with a sane alternative (preferably several sane alternatives: trying to do everything with one API is a large part of why DOM is as bad as it is), XML has run its course in software development—especially Web software development (and increasingly, that's the only kind of software development that matters). The W3C should address the needs of working developers and deprecate a bad spec when required.
In spite of the poor API, XML still allowed developers to work with a cross-platform data format supported by a many high-quality tools. And as common desktop applications are moving to XML-based formats, XML's role as a document format, instead of a programming tool, will grow in importance, writes Harold:
Now that all our office documents are in XML, it will become incredibly easy to transform them from one format to another. 2008 is the tenth anniversary of perhaps the single most game-changing technology in the XML family: XSLT. In its spanking new 2.0 version, it's even more powerful. Fairly soon, conversions between the competing formats will become so straightforward that most people will stop caring which format they're using...
Look for individual corporate developers and webmasters to begin publishing custom templates for their sites. This will enable regular folks to write in Microsoft Word as they're accustomed to doing and then upload their musings straight into the local content-management system. Editing and reviewing tools can be built right in. Because machines generate all the markup (the humans see the GUI interface they're used to), well-formedness will be a freebie. The majority of the Web won't be well-formed by the end of 2008, but a larger percentage will be than today.
Harold also mentions the emergence of the Atom Publishing Protocol (APP) as a key enabler for new XML-based Web functionality:
APP will do to do for Web authoring what HTTP did for Web browsing: provide a standard protocol that a variety of independent clients and servers can use to communicate without prior agreement or a shared conceptual model.
Independent software vendors can write their own authoring tools that talk to APP services on the different servers. These can be custom editors or plug-ins for products like Word and OpenOffice. Uploading content will be as simple as saving a file on the local hard drive is today, and in some cases simpler. Creating a new document will simply require a URL to POST to and a username and password. (Wiki-like sites might not need even the username and password.) To edit a document, you will need nothing more than the URL of that document.
Among other enabling technologies, Harold writes about XML databases, and the XQuery language.
> I will not be using XML (if I have a say) > > serialization
I just realized I'm using XML for serialization on a project right now. It wasn't my choice but it's actually not a bad option. I just don't deal with serialization that much.
Configuration and code is where XML really stinks.
I've said it before, and I'll say it again: XML is not the best format for storing data. DOM isn't the problem. The problem is inherent in XML's design. It was designed, after all, as an extensible markup language. A markup language is a language that is used to markup text (http://en.wikipedia.org/wiki/Markup_language). When your content isn't supposed to be interpreted as text, XML has an impedance mismatch.
As a concrete example, say you have a data format that splits a name into first, last, and middle name. Do you format the data like this:
The official XML answer would be, is "Harry", "S", and "Truman" part of the text? If so, put them in text elements like the first example. If not, put them in attributes. The obvious problem here is that when using XML to represent data, there is no text.
I bought and read ERHarold's XML Bible years ago, and I seem to recollect him referring to each XML file as a "document." A DTD is a Document Type Declaration, after all. Hence, I think of XML as suitable for what normal humans call "documents": books, articles, web pages, word processor products, etc.
I'm with James on not using XML for configuration and serialization. These days I'm a hobby programmer and home user, so I can't say I have much use for serialization. If I did, I imagine I'd use JSON or YAML if only because a serialized object is not a "document" in my mind. YAML is great for config files. It's so easy to type by hand when desired.
I currently use MathML, RecipeML, and SVG. I'm not sure whether MathML and SVG have much future, but I still figure on using them in the coming years.
I definitely see XML for word processor products, what with OpenOffice and all. I don't bother to use a WYSIWYG word processor, however. For power users who want to whip something up without a WYSIWYG editor, I see a future for wiki-like or perldoc-like markup converted to a "standard" XML document type such as a stripped-down DocBook, and vice versa.
Thinking about stuff that I'm not involved in, though, there's the whole issue of digitizing archived books, magazines, newspapers, etc. (In Rainbows End, Verner Vinge makes a hilarious jab at Google's efforts: a giant suck and shred machine). One key is preserving metadata, and for that you need something such as the Dublin Core XML tags.
> The obvious problem here is that when using XML to represent data, there is no text.
Unfortunately, many (including ERH on occasion) xml zealots display the Borg Attitude: all your data is Ours. They assert that Only The Tree is the One True Data Structure. IMS did that in 1964, and was soon enough replaced by Dr. Codd; it wasn't even the most robust database at the time. ERH makes a passing reference to Dr. Codd, but avoids the core issue and sounds (to my ears) dismissive. The Tree is NOT the One True Data Structure.
Those who ignore history... Who said that there was such a thing as Collective Intelligence? And so on...
IIn my world, I have a few different application areas where different storage formats are appropriate.
(A) Standardized binary formats with format verification and extensibility (B) Reasonable text serialization formats with the ability to represent arbitrary data structures (including graphs), with schema verification. (C) Document formatting (D) Configuration files (E) Other (e.g. relational databases)
XML fits for (C) - document formatting. It is sometimes reasonable to shoehorn into serving for (B) - serialization - due to the ability to do schema verification and the available tools for different languages. I would be much happier with having a schema system added to YAML than I would be with continuing to abuse XML, though.
For (A) - binary files, the best fit I have seen was the old Interchange File Format of the Amiga; a structured, extensible binary format that was easy to add things to, easy to read/write, and easy to parse (including giving human-readable variants). For most structured data, this was easier to deal with than XML - both for man and machine.
For (D) - configuration files - I would hope XML will die. Now. Or preferably a long time ago. XML add a bunch of noise to the configuration files, making it difficult to see the actual configuration; in my experience, custom languages (or in a pinch YAML) work much better. Maybe this is an area where it would be possible to create a common custom language that would work well; I don't know of any that I feel work well at the moment, though.
Ideally, I'd also like a common API based on the relational model (with extensions for hierarchy) for working with all these different formats. This is NOT like SQL; SQL mess up the model in a royal fashion, and get a lot of complexity from underlying mistakes. A plain API implementing the model in a straightway fashion would be MUCH simpler than SQL - after all, the relational algebra is just six operations.
I rather like the use of XML for the transfer of data between organisations, especially where fields of the data include text. GML (Geographic Modelling Language, an XML application) is a huge advance over any of the proprietary forms used in the past.
> I will not be using XML (if I have a say) > configuration
Last week I wrote a log4j.properties configuration file and decided to rewrite it as a log4j.xml configuration file since the log4j documentation seems to prefer that set up. A 1,700 byte file rapidly became a 5kb file containing the same data before being discarded.
> For (D) - configuration files - I would hope XML will die. > Now. Or preferably a long time ago. XML add a bunch of > f noise to the configuration files, making it difficult to > see the actual configuration; in my experience, custom > languages (or in a pinch YAML) work much better. Maybe > this is an area where it would be possible to create a > common custom language that would work well; I don't know > of any that I feel work well at the moment, though.
I've developed my own custom hierarchical configuration file format and an API in Java for working with hierarchical data from an unspecified source.. I got tired of working with lots of properties files and I detest XML configuration.
The API is really not that interesting. Sort of a simplified DOM model. If also introduces a simple dictionary type interface which can be implemented with a single method: get(String): String. Each node in the tree can be a value, a parent and a dictionary. It supports a simple path syntax.
The custom file format steals from Python's significant indentation and is basically like this:
config-a foo = 10 bar = hello config config-b foo = 12 bar = goodbye config-c foo = 15 bar = exiting
It does not support a relational model but I'd be interested more about how something like that would be implemented.
The thing about the API is that it really doesn't care where this configuration came from. I haven't done so but I could very easily make this API be fed from XML. The XML you would be allowed to use would be constrained, most likely, but in practice the use of XML is constrained in different contexts. But that's not the point, the point is to get away from XML so JSON maybe YAML could also feed into the same API and anything else you can think of with a basic hierarchical structure.
> DOM isn't a least-common-denominator API: it's a worst-common-denominator API.
Yes it is.
Our engineers used to call the APIs "sucks and dumb" instead of "SAX and DOM" ..
But because it was provided for free and was available early on, almost no one has the temerity to point out that it was designed by monkeys with forks shoved into their brains.
If on the other hand it were proprietary or from Microsoft (or any equally derided company), everyone would have made fun of it as the pile of junk that it is.
> For (A) - binary files, the best fit I have seen was the > old Interchange File Format of the Amiga; a structured, > extensible binary format that was easy to add things to, > easy to read/write, and easy to parse (including giving > human-readable variants). For most structured data, this > was easier to deal with than XML - both for man and > machine.
In the future, I'll be using XML as I do today...only if I can't avoid it.
In the vein of JSON and YAML, and tying into the reference to Amiga's IFF, the architect of the Amiga OS--Carl Sassenrath--designed REBOL. It was originally marketed as a "messaging language", but nobody knew what that was.
With REBOL, as with the goal of JSON, I don't have to program in one language and use another for data. It's definitely not for everybody, but it makes me happy.
Configuration files that don't give me the ability to annotate or insert my own additional parameters and structures mean I can't subclass and extend an application.
Anything relying on whitespace delimitation - correct indents and correct linefeeds causes difficulties going cross-platform and often causes errors when copied and pasted from web pages or emails.
> Configuration files that don't give me the ability to > annotate or insert my own additional parameters and > structures mean I can't subclass and extend an > application.
This ability is a result of the configure code which you write, and which processes the configuration file, not the (xml) parser. A fact which is routinely ignored. It's your configure code which does the heavy lifting, not the (xml) parser. The parser merely converts the text to another form upon which your configure code then does the heavy lifting.
Flat View: This topic has 21 replies
on 2 pages
[
12
|
»
]
Previous Topic
