Elliotte Rusty Harold says, "Far and away the most common problem I've seen has been with namespaces. Namespaces are a real pain. They are difficult to understand. They are poorly designed. And a lot of the APIs that are out there either deliberately or accidentally try to pretend that namespaces are something other than what they actually are."

Read this Artima.com interview:

http://www.artima.com/intv/xmlapis.html

Here's an excerpt:

Elliotte Rusty Harold: It is one of the rules in SQL that the records have no fundamental order, that the fields in a record have no real order. It's just a question of how the query wants you to order the records. However, in XML in many cases, order is very important. Let's say you're just marking up normal human language like we're talking now. If we just start words switching randomly forth back and, to follow very hard becomes it. And that's true for many other cases, such as mathematical equations marked up in MathML.

Now it 's not true in all cases. You may have very database-like, very record-like XML. An RSS document, for example, contains many different items. Each item has a title, a URL, a summary. You don't really care whether the title comes before the URL or the summary. It will all be put into the right place when the document processed. But that's not all XML.

What do you think of Elliotte Rusty Harold's comments?

The point is moot. XML is a tree based structure. Objects in OO are also inherently tree based. Hence it's quite easy to map XML to OO and vice versa. The problem is that trees aren't very powerful structures especially when it comes to queries. That's why things like XPath are so weak.

We don't need tree based data to have a self describing data format. The major flaw of XML is that it imposes a single data structure on us via the XML layout. That's too serious a limitation to forego for any practical applications.

"Light is made of particles. No, Light is a wave, No..."
In the field of physics, scientists have had similar problems and have matured beyond caring what something "is", to merely what is the most convenient model for the task at hand.

This is how we should treat XML and XML APIs.

Your statement, "XML is a tree..." defies that premise and may cause you to do something the hard way rather than just adjusting you mental model of what XML "is" or "seems to be" or "can be thought of at this moment to get the job done".

The problems raised in the provocation message for this thread are valid, but almost entirely academic. For those of us who use XML to provide value to customers, it really doesn't matter how accurately XML has been modelled by some particular API until it doesn't let us do something we need to do or it makes it hard to it well or fast.

Hopefully folks like the author will continue to develop more and more options for us.

Pragamatism!

The comparisons with SQL and RDBMS technology are probably misguided. I prefer to think of XML as the "results" of some query (or in more OO-speak, the response to some message).

XML is probably, no definitely, not the most efficient means of storing data, nor do I believe it was designed or intended for that purpose in the way that the relational model was intended to represent persistent data and SQL developed as a means of accessing that information.

As such, some of the problems are caused by trying to model XML APIs as SQL-equivalents. We don't use SQL to iterate ResultSets. And XML documents are usually more complex than ResultSets. Unfortunately, the vocabulary of XML specs doesn't help (i.e., XQuery).

I have personally been satisfied with the API variants already available, having used DOM, SAX, and lately JAXB, to consume XML produced by other applications. And I would rather see those improved/standardized, than to keep learning new APIs, especially if the newer APIs do not resolve any issue affecting me.

I am especially fond of returning XML Documents to Internet Explorer and using client-side transformations to produce HTML for presentation. In many cases, the data sent to the browser is 25% of the HTML that would otherwise have been streamed. For low-bandwidth users, that can be really helpful! And this can be done with XML 1.0 DOM and the working draft of XSL.

Can you explain how mixed content is not consistent with objects?

Mixed content is a set of ordered anonymous members.

Someone said they thought of xml as an output of an sql database query.

Database tables are rectangular structures of rows and columns. Each row has the same column structure. They are "flat like the old world" before Christopher Columbus and Galileo. A query mapped into xml will be "very flat", like its query which is like its table or relationship of tables.

What is so very nice about using using xml for data storage that is next to impossble to do in a table is that an element can have as many children as needed each of can have as many children as needed ... I notice java forum responses that stick whole xml documents in database tables as blobs. Because its not so easy to put a growable tree into a table like you can with an xml document. The tree can grow as many branches and leaves as needed.

All this xml stuff grew out of Graph Theory, an abstract branch of Mathematics.

There are trees, forests, cut sets, cyclic graphs, random walks and all kinds of abstractions in GraphTheory that can be applied with xml processing. This power probably has not been tapped yet. It is waiting to be discovered in the "new world."

I got my question backwards.

What I meant was: I don't think ordered, anonymous, members are consistent with the OO languages I use.

I think he's bang on as far as the limitations and comparing XML strategies. Another thing (not sure if it's going into the next installment) is the lack of a cursor within a tree-based structure.

XML is like duct tape: it's a handy man's secret weapon - it goes pretty much anywhere and everywhere. You can even use it to make men's underwear.