The article introduces a real issue: the OO paradigm vs the XML paradigm when both are used for software development.

The main issue is not really in the "data" field, but in the "document" field: the mapping from a mixed content element to a class (ie a structure) is not clear.

Some articles about UML/XSD don't even talk about the issue (eg http://xmlmodeling.com/articles/IntegratingXMLData.pdf). Other consider an UML decoration ({mixed=true}) but don't go further in explanations.

The only mapping I see is to consider that a mixed content object is a collection of objects, some being strings, some being complex objects.

But what kind of standardized "high level" object interface can we create to handle this properly?

Let's take a step back when comparing XML to UML. No where does the author of the original article state tat XML is a modeling language like UML. Rather the author suggests that describing a data model in XML Schema is more powerful than other conventional methods.

I personally believe this is absolutely true. In UML, how would you specify that a data field must be 32 characters in length and consist of the character set [A-F]?

My point is that we should not slam the author for something he didn't say.

So your data model is and was designed using XML/XML Schema. Great. Now where do you put the data? Can you really relate it in the ways you need to in storage?

I'm a big fan of XML and native XML storage solutions like Excelon. But its unclear to me where the editor wants to go with this idea. Most will look to shred or blob their XML.

Just because a technology can do something in no way means that it will pay to do so. XML is not a silver bullet, but is instead a nice if still very incomplete data interchange technology.

With regard to "XML schema is an inferior modeling language compared to UML/OO design", more good points! And more good reason to take a look at the Water language, because all of these points are answered within it.

Some good points in this article, but why stop at using XML syntax for data modelling? Why not also use it for a programming language syntax? Why not have the language evaluate as a method call? This not only brings programming's dynamism to the XML customarily considered static, but also lets you stop banging your head mastering the next darned Java-to-task-specific-XML API: Just emit/accept XML directly from/to the object system and get to work using it.

For example, see www.waterlanguage.org.

The idea expressed in this article is the current dogma at my organization. This idea has great allure. Why bother to learn UML and OO design when you can just use XMLSpy or other GUI XSD authoring tool, and voila! behold the data model !

In my opinion this idea is naive and greatly misguided. This idea may work if the data structures are simple such as is the case with simple 1-n, and n-n relationships, with no associative arrays/hashmaps or complex db joins.

I strongly disagree with the statement that XML Schema has more expressiveness than programming types. This may be the case if you are using Visual Basic, or C, perhaps, but it is definitely not the case when you are using Java/UML where you have available all the expressiveness of OO design, and the richness of libraries such as the Collections framework.

For example, an XML representation of a 3-way join within a relational db, cannot easily be represented in an XSD, compared to defining an interface that returns, for example, a HashMap of Arrays indexed by some Business Code.

If you have ever tried to design a complex Business Domain with XSDs (schema language) you will quickly get annoyed with the schema extension mechanism which requires that you add nodes to extend Common Types, which results in corresponding additional classes and artifacts in the source code.

This is aggravated by the proliferation of tools like XMLSpy which make it really easy to design poor schemas through a GUI by would-be modelers who never bother to read the XML Schema specification and factor the functionality of the application.

I'd be interested to know how many complex applications the author has built using the idea expressed in this article...