Dancing DOM to DOM

Several years ago, I was involved in a project for my day job where the client was browser based and the server was called strictly using SOAP. Even though the server was built on .NET, we decided not to create .NET types (classes or datasets) to represent parts of the SOAP messages. Instead, we just defined types using XML Schema and associated those types with message parts using a custom attribute.

The client was the browser (JavaScript) and the server received non-scalar message parts as .NET XmlDocument instances. So, the programming environment on both sides was DOM-oriented. Data access on both ends was done using predominantly XPath, SelectNode(s), and other DOM API calls.

I was later asked how the development team adjusted to a world without strong types. Was there a riot? Actually, there were worries about type safety, conversion between XML simple types and C# intrinsic types (yes, dates had to be closely managed), or the lack of a nice object hierarchy.

There was one complaint, though: no Intellisense.

Is that all we need to really send XML, web services, etc. to some next level of adoption? So, for all of the Visual Studio and Eclipse dudes out there, how hard could it be to attribute some DOM type with a schema QName and then get some IDE help when creating an XPath statement? If it’s doable, let me know!

One other issue was that Intranet single-sign-on is still hard and the solutions are very platform-specific. WS-Security is probably a great next step, but unless it gets implemented in the browsers (part of XMLHTTPRequest?) it will have to come by way of a plug-in.

Some people look at the DOM API and see a big stick of ugly. But the complaining dies down after realizing that XML messages have interesting, interoperable capabilities to compose messages. The skillsets are also reusable (meaning lucrative) in web programming.