XML and OO (where the wires?)

Bill MacCarthy has hit on a subject that is one of my pet complaints ...

The relationship between XML and OO. You see my wish is to see XML as objects and this is a debate I want to bring here to C9.

Do you agree or disagree with me?

Yes, I know we can talk about DOM and XLinq but it's still not easy enough.

Sabot wrote:

The relationship between XML and OO. You see my wish is to see XML as objects and this is a debate I want to bring here to C9.

You'll have to narrow it down a bit, I think. Which debate are we having right now?
I'll try to play along, hoping I'm on the same wavelength.

I agree that XML's fluid schema and intrinsically heirarchical nature make it convenient for storing object graphs. It's icky to normalize everything and spread it around several tables when we have a single object in hand. A normalized table makes it easier to treat objects as first-class entities in our system. Having XML nodes that are simply references to different nodes kind of defeats the purpose of using an XML tree, doesn't it?

Consider these two examples:

<customers>
   <customer name="Sabot">
      <order id="AAAA-7" >
         <Insert various order details here>
      </order>
   </customer>
</customers>

As opposed to:

<customers>
   <customer name="Sabot">
      <order id="AAAA-7" />
   </customer>
</customers>

<orders>
   <order id="AAAA-7" >
      <Insert various order details here>
   </order>
</orders>

The first is more "natural XML" - it gives you a hierarchical representation of your relationships. The problem with it is that it doesn't give you an n..n relationship that a normalized solution, like the second example does - we might not need an n..n relationship in a customer/order scenario, but it will often come up in other cases, and anyway, it restricts us from treating Orders as first-class entities. In effect, the hierarchical relationship becomes a context - in example #1, order AAAA-7 exists only in the context of the Sabot customer, so if I want a report of all orders, I'm actively ripping my relationship heirarchies and ignoring my structure.

What I do feel, however, is that XML structures are good as one-off structures. Need to display a customer/order treeview? Take your normalized data from example #2 and transform it into the hierarchical structure from #1. Need it the other way around? No problem - write a new transformation.

Did I mention I like XSLT?

Hmm. The end goal confuses me a bit. Xml is just a text format of brackets and attributes - it is just a representation of data. The interesting things are what we can do with such a simple and transferable representation of data.

Yet, I want to be as far away from working in angle brackets as I can be. If something can be so defined such that it can work as a message to disparate systems, that's great. As a language it is verbose and ugly, as a representation on the wire or in memory it is often overly large.

To compare XML and OO in some way doesn't make much sense to me. XML must always be parsed, and interpreted in some fashion. As the parsers and intepreters move up the complexity value chain it becomes more invisible to the end user and may seem to take on magical properties. But, XML is still just that text representation.

XML can be treated as an object when it is translated into an object system. This doesn't allow us to remove the object system.

Am I missing something in this interpretation?

I gave up on trying to do stronly typed xml using serialisation or data binding, the schema I'm working to is just too complicated for most of the tools. Instead I just wrote a load of classes that can persist themselves to an XmlWriter and initialise themselves from an XmlReader.

It's really quick, I can store the data much more efficiently, and I have complete control over the output structure.

I'd like to see where the tools lead with typed xml on top of XLinq, but I'm not convinced it will ever be flexible enough as a mapping layer.

Ralf Lammal has some really interesting papers on the subject though.

I think I know where you're coming from. Having spent a lot of time working with WPF where objects have an XML representation and a code representation so you could serailise any object to text files and perform other nicities. Going the other way would be cool too.

Imagine using XSLT you could transform one object to another one. Could be interesting?

blowdart wrote:

An object to me is not just the data, but the methods as well. Unless of course you simply have a object that holds data, and you're taking aspect orientated to extremes

How do you feel about this little entity?

<orders onOrderRemoved="updateCustomer" onOrderDelivered="updateInventory">
</orders>

The actual implementation of the business logic isn't in XML, of course, but the object it represents encapsulates both the data and the methods.

Or, to be more explicit, this fictional block I just invented:

<user>
   <name>blowdart</name>
   <address>Channel9</address>
   <method name="getPostCount" retVal="System.Int32" language="c#">[[CDATA[
    return new C9Provider().GetPostCount("blowdart");
     ]]
   </method>
</user>

In this case we have actual business logic embedded in the XML block.

A statically typed language could take these XML blocks and compile them into objects - the 'blowdart' instance would be of the User__Blowdart type, which inherits User and has an additional method called getPostCount.
Dynamically typed languages, of course, would just do this automatically.

blowdart wrote:

To me it doesn't. Encapsulation is the inclusion of everything an object needs to do it's job, right? Except that's not what you have here, you have what is needed for an external engine to drive the job, because something else has to provide updateCustomer and updateInventory. You have some business logic in the mtehod names, but the heavy lifting is encapsulated in methods elsewhere, obviously, and you are relying on those methods as expected.

First of all, you're ignoring my second example which includes just that, the logic and all.

Secondly, I disagree with your general claim. No-one's going for an all-or-nothing XML-and-nothing-but approach. What Sabot may have originally meant (Hey, Sabot! Join in!) was the ability to use XML to describe my business objects, thus easily converting my data into operable chunks. This means that this:

<customer deletable="true" id="5">
   <orders>...</orders>
</customer>

Will, by defining these data properties, automatically and implicitly create operational methods:

Customer myCust = new Customer();
int id = myCust.ID;
Orders orders = myCust.GetOrders();
myCust.Delete();

All these properties and operations are implicit in the XML structure above - the assumption being that the operations I want to perform on my data are, by definition, related to my data, or to its metadata - relationships, etc.

blowdart wrote:

But it's the implicity (is that a word?) that I object to. Because the implicitness (is that a word too?) relys on what's underneath, not the structure of the XML. The deserialisation methods are in charge, and they're not part of your objects.

But I will hold that there is always some measure of implicititation (I know that's not a word). Even if we embed code directly, like my other example, we're still relying on some implicit mechanism that will call that code.
When we have a heirarchical link between the <customer> and <orders> tags, we're relying on implicit logic that links those together.

We're still relying on the structure of XML to express the relationships between objects. There's no conceptual different between this, relying on tool-generated code:

Orders orders = myCustomer.GetOrders();

And this, using the XML representation directly:

XmlNode orders = myCustomerNode.SelectSingleNode("orders");

They're equivalent, except for one having the implicit relationship from the XML heirarchy turned into an explicit code-based relationship. This is exactly the sort of process that the Typed Dataset generation tool does, and is a good example of XML -> OO mapping.