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.'"

Comments

"How will you use XML in years to come?"

[Ant P.]

Sparingly. JSON is just plain better, and doesn't inflict an enterprisey mindset on anyone that tries to use it.

Re:"How will you use XML in years to come?"

[MagikSlinger]

Sparingly. JSON is just plain better, and doesn't inflict an enterprisey mindset on anyone that tries to use it.

JSON is inflicting Javascript on everyone. There are other programming languages out there. Also, XML can painlessly create meta-documents made up of other people's XML documents.

Re:"How will you use XML in years to come?"

[MagikSlinger]

JSON is inflicting Javascript on everyone.

No, it really doesn't, but if "JavaScript" in the name bothers you, you might feel better with YAML.

No, it wouldn't because JSON is bare bones data. It's simply nested hash tables, arrays and strings. XML does much more than that. XML can represent a lot of information in a simple, easy-to-understand format. JSON strips it out for speed & efficiency. Which sort of gets into the point I did want to make but was too impatient to explain: JSON is good where JSON is best, and XML is good where XML is best. I dislike the one-uber-alles arguments because it's ignoring other situations and their needs.

There are other programming languages out there.

And there are JSON and/or YAML libraries for quite a lot of them. So what?

Would you like to live in a world of S-expressions? The LISP people would point out there are libraries to read/write S-expressions, so why use JSON? The answer of course is that we want more than simply nesting lists of strings. We want our markup languages to fit our requirements, not the other way around. And saying "JSON for Everything", which the original poster did was... silly.

My problems with JSON are:

• No schema: XML Schema not only makes it easier to unit test, but it can be fed into tools that can do useful things like automatic creation of Java classes and code to read/write. Does JSON have anything like that? Of course not, because it would defeat JSON's purpose: easy Javascript data transmission.
• Expressability: With XML, I can create a model that fits my logical model of the data where I use attributes to augment the data in the child elements. Doing that in JSON is a kludge with a hash-table to represent an element which can't be easily converted into a graph for easy understanding.
• Diversity: I use GML in my day job. A lot. I can easily set up an object conversion rule with Jakarta Digester that I can painlessly drop into future projects without modification. That's the power of namespaces. I can build an XML document using tags from a dozen different schema, and then feed it to another application that only looks for the tags it cares about.
• XPath. 'Nuff said. Ok, one thing: this should have replaced SAX/DOM years ago.

JSON is great for AJAX where XML is clunky and a little bit slower (my own speed tests hasn't shown there's a huge hit, but it is significant). XML is great for document-type data like formatted documents or electronic data interchange between heavy-weight processes. My point was that the original poster's JSON is everything was narrow-minded, and that XML answers a very specific need. There are tonnes of mark-up languages out there, and I think XML is a great machine-based language. I hate it when humans have to write XML to configure something though. That really ticks me off. But that's the point: there should not be one mark-up language to rule them all. A mark-up language for every purpose.

Re:"How will you use XML in years to come?"

[aoteoroa]

Hear! Hear!

One file (format) will not rule them all.

XML is good if you want to design a communication protocol between your software, and some other unknown program.

JSON is much lighter. Far less kilobits needed to transfer the same information so when performance is important and you control everything then use JSON.

When it comes to humans editing config files I find traditional ini files, or .properties easier to read and perfectly suitable in most cases.

Writing more complex, relational data to disk? Sqlite often solves the problem quickly.

Re:"How will you use XML in years to come?"

[CoughDropAddict]

I'm so depressed. You represent an entire generation of programmers who can't figure out the difference between marked-up text and data, and why mark-up languages suck so bad for data interchange.

Pop quiz. Here's an excerpt of GML from that page you linked to.

<gml:coordinates>100,200</gml:coordinates>

Do the contents of this node represent:

1. the text string "100,200"
2. the number 100200 (with a customary comma for nice formatting)
3. the number 100.2 (hey, that's the way that the crazy Europeans do it)
4. a tuple of two numbers: 100 and 200

"Obviously it's two numbers, they're coordinates" you may say. But such things are not "obvious" to an XML parser. If you're an XML parser the answer is (1): it's a simple text string. So to get to the real data you have to parse that text string again to split on a comma, and to turn the two resulting text strings into numbers. Note this is a completely separate parser and is completely outside the XML data model, so all your fancy schema validation, xpath, etc. are useless to access data at this level.

Why all this pain? Because XML simply has no way to say "this is a list of things" or "this is a number."

Sure, you can approximate such things. You could write something like:

<gml:coordinates>
    <gml:coordinateX>100</gml:coordinateX>
    <gml:coordinateY>200</gml:coordinateY>
</gml:coordinates>

But the fact remains that even though you may intuitively understand this to be two coordinates when you look at it (and at least you can select the coordinates individually with xpath in this example, but they're still strings, not numbers) to XML this is still nothing but a tree of nodes.

Did you catch that? A tree of nodes. You're taking a concept which is logically a pair of integers, and encoding it in a format that's representing it in a tree of nodes. Specifically, that tree looks something like this:

elementNode name=gml:coordinates
\-> textNode, text="\n " *
\-> elementNode name=gml:coordinateX
    \-> textNode text="100"
\-> textNode, text="\n " *
\-> elementNode name=gml:coordinateY
    \-> textNode, text="200"
\-> textNode, text="\n" *

(*: yep, it keeps all that whitespace that you only intended for formatting. XML is a text markup language, so all text anywhere in the document is significant to the parser.)

So let's recap. Using XML, we've taken a structure which is logically just a pair of integers and encoded it as a tree of 7 nodes, three of which are meaningless whitespace that was only put there for formatting, and even after all this XML has no clue that what we're dealing with is a pair of integers.

Now let's try this example in JSON:

{"coordinates": [100, 200]}

JSON knows two things that your fancy shmancy XML parser will never know: that 100 and 200 are numbers, and that they are two elements of an array (which might be more appropriately thought of as a "tuple" in this context). It's smart enough to know that the whitespace is not significant, it doesn't build this complex and meaningless node tree; it just lets you express, directly and succinctly, the data you are trying to encode.

That's because JSON is a data format, and XML is a marked up text format. But we're suffering from the fact that no one realized this ten years ago, and compensated for the parity mismatch by layering mountains of horribly complex software on top of XML instead of just using something that is actually good at data interchange.

Re:"How will you use XML in years to come?"

[dkf]

My problems with JSON are:

• No schema: XML Schema not only makes it easier to unit test, but it can be fed into tools that can do useful things like automatic creation of Java classes and code to read/write. Does JSON have anything like that? Of course not, because it would defeat JSON's purpose: easy Javascript data transmission.

While I hate XML Schema, it's still better for many uses than just throwing random crap on the wire and hoping that the other end can make sense of it. And no, throwing some javascript on the wire as well doesn't help that much. I want the computer to do stuff with the data without having to ship a program specifically for the purpose; after all, I can't think of all the purposes for the data right now and I want to let others come up with new cool stuff too.

• XPath. 'Nuff said. Ok, one thing: this should have replaced SAX/DOM years ago.

I use a DOM library that includes XPath support so that I can simply do a search starting at any node. It makes working with DOM much more pleasant.

I hate it when humans have to write XML to configure something though. That really ticks me off. Simpler stuff works quite well when you've got configuration of software from a single vendor, but when you've got to combine stuff from lots of sources, XML stops being quite such a bad choice. (If only people who edit config files would actually demonstrate an ability to write well-formed XML though. Idiots...)

Re:"How will you use XML in years to come?"

[Anonymous Coward]

You are arguing the merits of isolated XML, while in fact it is a collective technology. Yes, the XML itself is not strongly typed, that is why you have SCHEMA (formerly DTD). Using XML-SCHEMA (coincidently also written in XML) you DO get a strongly typed document where you can say that a tag can only contain one letter followed by 12 digits or whatever. Then you can use XSL to transform the document, knowing with certainty every single bit of the format.

The only difference here is that XML separates these 3 (markup, validation, transformation) operations, since you might find situations where you don't need all of them.

I don't understand...

[ilovegeorgebush]

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?

Re:I don't understand...

[SpaceHamster]

My best stab at the popularity:

1. Looks a lot like HTML. "Oh, it has angle brackets, I know this!"
2. Inertia.
3. Has features that make it a good choice for business: schemas and validation, transforms, namespaces, a type system.
4. Inertia.

There just isn't that much need to switch. Modern parsers/hardware make the slowness argument moot, and everyone knows how to work with it.

As an interchange format with javascript (and other dynamically typed languages) it is sub-optimal for a number of reasons, and so an alternative, JSON has developed which fills that particular niche. But when I sit down to right yet another line of business app, my default format is going to be XML, and will be for the foreseeable future.

Re:I don't understand...

[GodfatherofSoul]

XML gives you a parsable standard on two levels; generic XML syntax and specific to your protocol via schemas. It's verbose enough to allow by-hand manual editing while the syntax will catch any errors save semantic errors you'll likely have. It's also a little more versatile as far as the syntax goes. Yes, there are less verbose parsing syntaxes out there, but you always seem to lose something when it comes to manual viewing or editing.

Plus, as far as writing parsers, why burn the time when there are so many tools for XML out there? It's a design choice I suppose like every other one; i.e. what are you losing/gaining by DIYing? Personally, I love XML and regret that it hasn't taken off more. Especially in the area of network protocols. People have been trying to shove everything into an HTML pipe, when XML over the much underrated BEEP is a far more versatile. There are costs, though as you've already mentioned.

Re:I don't understand...

[Anonymous Coward]

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.

Because it's a standard that everyone (even reluctantly) can agree on.

Because there are well-debugged libraries for reading, writing and manipulating it.

Because (as a last resort) text is easy to manipulate with scripting languages like perl and python.

Because if verbosity is a problem, text compresses very well.

Re:I don't understand...

[batkiwi]

XML IS:
-Easily validated
-Easily parsed
-Easily compressed (in transit or stored)
-Human readable in case of emergency
-Easily extendable

Re:I don't understand...

[Anonymous Coward]

For one, it has off-the-shelf parsers and validation tools. Parsing XML is, at it's hardest, a matter of writing a SAX parser. XML binding APIs make things even easier. The standardized validation tools also make it great for ensuring that people in charge of generating the data are using the form expected by those receiving the data.

Our biggest usage is in our customer data feeds. These feeds are often 1GB+ when compressed. Since switching to an XML format from a tab-delimited format, we've been able to give our customers an XSD to validate the file before sending it to us. The result has been far fewer round trips between us and our customers before receiving an acceptable feed. As you can probably imagine, fewer round trips is a very good thing when each round trip involves sending 1GB+ of data over the internet.

Also, gzip and other compression methods do very well with XML files...to the point where the difference between a compressed XML file and a compressed JSON or other formatting of the same data is pretty minimal. So your point about AJAX applications isn't particularly relevant once you've enabled gzip content coding.

The human-readable benefit is more of a nice side effect rather than a must have, though it does come in quite handy when debugging.

So you might want to ask yourself why not use it? What are the drawbacks of your CAD program using XML to store its files, especially if it does something like OpenOffice does by compressing them. Why not take advantage of tools that make it simple to parse information? If it's just the "XML is bulky" complaint, that's basically been addressed.

Re:I don't understand...

[Xtifr]

From an academic viewpoint, it probably matters. From a point of view of trying to get the job done...not so much. I studied the performance and efficiency of a wide variety of sort algorithms when I was in school, but nowadays, I generally just call some library to do my sorting for me. It may not be quite as efficient for the machine to use some random, generic sort, but for me, it's the difference between a few seconds to type "sort" vs. a few hours to code and debug a sort routine that is probably, at best, only a few percent faster.

XML is, in many cases (including mine), the path of least resistance. It's not particularly fast or efficient, but it's simple and quick and I don't have to spend hours documenting my formats for the dozens of other people in the company who have to use my data. Many of whom are probably not programmers by Dewar and Schonberg's definition, but who still do valuable work for the company.

Re:I don't understand...

[Otto]

-Easily compressed (in transit or stored)

Which just means that it has lots of redundancy. Or, as one might call it, bloat. Test question: Which is quicker?
1. Spending a few hours coding your formats in some binary format making maximum use of all the bits.
2. Spending a few minutes writing code to send your internal data structure to a library that will serialize it into XML and then running the XML through a generic compression routine (if space/speed actually makes any difference to your particular application).

Consider the question in both the short and the long term. Also consider that you're paying that programmer a few hundred an hour.

Discuss.

Re:Too many 'this stuff sucks' moments

[QRDeNameland]

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.