You might say that a Schema provides 'strong typing' (in accordance with the notion of strongly typed programming models) to XML and that declaration of a schema is equivalent to a type declaration. [codaland]

This is where the type mapping analogy falls apart for me. In OO, the goal is to associate operations with data, but in Schema, where are the operations?. Now Mr. codaland realizes this, because later he says

This may lead to the inevitable conclusion that the Object-Oriented paradigm, in which data and behavior are encapsulated within the same entity, is inherently superior to the XML (data-oriented) paradigm.

I think that conclusion is inevitable if you expect your XML to connote behavior. That's going to lead to frustration. I come from an OO background as well and this point didn't sink in for a while; I was one of the people dismissing DTDs and clamoring for schemas back in 1998. In fact, I avoided working with XML for a while because it lacked strong typing.

I work in the travel industry, and one thing that's happened over the years is that there's been a number of efforts to create a standard library of business objects for interchange. Without exception, every one of those efforts has failed. Now some of that may be due to complexity, or to competitive pressures, or to hyper-abstraction, but my belief is that the basic problem is that the philosophy is flawed. Now, there's an effort to standardize XML formats, the OTA. From the recent news, it sounds like this group has more or less gone down the object mapping path. I submit that what we in the travel industry are and should be exchanging documents. Take the simple case, air availability. What this transaction does is tell you what airlines offer flights between a given origin and destination within specified parameters. The results are more or less a list of flights (often in pairs or threes to complete a routing when a direct one isn't suitable) with estimated inventory levels. But these aren't flight objects. They're representations of flights, with partial information about the flight, but only enough that you can turn around and say "I want in-flight service information on this flight", or "I want to book this flight". So if you create an object, it's an object with a bunch of get operations, because you can't change the flight number because you think it's unlucky, or change the vendor because you don't like them. The data is immutable, you don't own it and there's not really any useful operations you can do on it, so why not let it be data, and not an object? To me, that's the point. Not everything has has to be an object. OO is one way of looking at the world and organizing code, but not the only way. Sometimes, it's the wrong way.

There's an organized line of thinking in here, but I need to go into work and slay the deployment beast, so to speak. Clemens is writing a ton of interesting stuff, too, but right now I'm just in too much of a time crunch to digest everything properly. More later.

Clemens is right about anonymity, BTW, and as Justin mentioned, I also wish you had an RSS feed. Though given that blogspot.com is too personal for my employer, I may not get to read that either.

NOT HOT. My blog is most definitely not HOT [Be Blogging]

When I saw how Ugo rated, I decided that I didn't need to take part in this. This is a fun toy, but ultimately there's more true methods of getting feedback on your writing.