XML != Object

Confusion arises because there's no commonly accepted definition of what an object is, let alone what an object model is. XML schema definitions map to some languages' OO concepts cleanly in some aspects and don't map at all in other aspects. One commonly used definition of an object is state plus behavior. Web services certainly don't support that definition.

In other words, there are lots of different "object-oriented" viewpoints. How exactly do you model XML's "inheritance by restriction" in C#, for example?

SOAP and XML don't talk about objects at all really. They describe structured data. These are considerably different. I'm not saying it's not useful to map structured state to/from objects. But when you pass a DataSet, or a Queue, or similar "objects' you are no longer passing structured state alone, IMO, because such .NET classes also have behavior that you are not passing.

-- Brent Rector on the DOTNET-CLR list.

This is one of the points that Dare brought up in his article on XML.com. 

this kind of derivation does not neatly map to concepts in either object oriented programming or relational database theory, which are the primary producers and consumers of XML data.

This is a very large part of the problem of web services and their proliferation in.NET.  There has been so much focus on the OO aspects of .NET that many developers seem stuck in Design Patterns, so much that they don't take into account that the “objects” they are passing around are really just XML messages that represent the serialized form of those objects.  The WebMethodAttribute attribute in .NET hides the XML-ness of web services to the point that SOAP and its XML roots becomes nearly irrelevant. 

This is not a Good Thing.

I have talked at many user groups about XML and .NET, and at each of them I show how to pass XML as an HTTP POST to an ASP.NET page, load the XML up into a DOM or XmlReader, and process it.  When I draw the correlation to SOAP message passing, you can see their eyes glaze, as if asking “what do web services have to do with XML?” 

SOAP is XML, and XML is just data.  It provides rules for how data can be structured so that different parsers can understand the same structure and process it.  Yet there seems to be a notion that somehow SOAP adds behaviors onto XML.  This is no more true than if I wrote my own XML message:

<message action=”Say”>

  <param type=”text”>Hello</param>

</message>

This is just data, and it is up to the consumer of that data to figure out what to do with it.  My processor may determine that it needs to initiate a device to play a recording of someone saying “hello”, or I may just use the data to create JavaScript in HTML using an alert box.  The point is that it is up to the consumer of the XML to understand what to do with the data.   The mere fact that my data contains a SOAP envelope structure or has WSE 2.0 header information in it conveys nothing to the consumer unless the consumerr understands that the presence of certain data elements should cause the processor to initiate some action.

XML is not about objects, it does not convey behavior.  There are even limited mappings from XML concepts to those of the OO world.