Things have been quiet on the weblog front recently – I’ve been putting in some hours on my research and preparing for the Microsoft Architect Forum next Monday (I am the… case study). And there is always my job.

Anyway, I am a month late on this but Microsoft have dropped XQuery support from the next version of .Net. Looks like I will be using Saxon for a while.

I went Christmas shopping for my family on Saturday, I think this was my first day off in about four weeks. I didn’t find much for them, but I want a Gaggia Cubika.

Microsoft have released the first part of their DSL/MDD effort: Microsoft Tools for Domain Specific Languages. Stuart Kent’s blog has more.

Early signs are promising – I managed to put together the meta-model for my research project in under 10 minutes. Can’t wait to actually do something with this, e.g. create a designer.

Number of results for “xml” on Amazon: 5000+

Number of results for “xml anti-pattern” on Google: A couple.

I’m working with XML

I’m playing around with using XQuery to write queries against an XML representation of .Net code via PERWAPI. This feels a bit like selling my soul to the XML devil, so by way of atonement I’m going to identify some poor applications of XML, rant for about 10 paragraphs, then get back to work.

The beauty of XML: there are plenty of parsers, it’s easy to specify a format, it’s extensible and human readable. XML makes a lot of sense when integrating systems that are developed separately, built on different platforms, or communicate across organisational boundaries.

However: it’s all pretty insignificant when the same group of people are building closely related components on the same platform. Applying XML inside systems doesn’t have much upside. In fact, it can get ugly very, very quickly.

Procedural thinking

XML’s ‘extensibility’ and ‘flexibility’ provides a convenient banner for anyone who wants to write shoddy procedural code, but doesn’t want to admit it. Ever seen a sequence of tightly coupled methods that manipulate the same Xml document, passed between them? These kind of methods often have a single parameter called “data” which carries some XML, conforming to god knows what schema and being XPathed and hacked on with abandon.

That’s degenerate procedural programming under an XML guise. In this case, XML allows a generally poor design to masquerade as an open, flexible one – this sort of design may be touted as a sort of pipeline or chain of responsibility or some other pattern, but I’d call it “veneer of respectability”.

So what’s wrong with code like this? Only everything that’s wrong with procedural programming – the tendency towards poor encapsulation, separation of behaviour and state, and duplicated functionality.

Take my compiler, please!

Interfaces look a whole lot neater when a bunch of different parameters get rolled up into one big XML document. For example, I can turn this:

Customer GetCustomer(String surname, String firstName, PostCode code, bool isPartialLoad)

…into this…

XmlDocument GetCustomer(XmlDocument details)

…with just a sprinkle of XML. Problem is, unless you’re working with Comega, you get absolutely no compile-time checking. If you like the thrill of blowing up at runtime while coercing types, this approach will suit you down to the ground.

Perf

Last time I checked, pulling data out of an XML document with an XPath expression was about 100,000 times slower than getting it through a property accessor. That’s not counting the cast that’s probably needed to actually use the data. For distributed systems, XML bloat is another perf problem. Big documents on the wire make for slow, error prone systems.

And by the way: O/R mapping just got worse

O/R mapping has proved tough to crack – most mapping is still hand-rolled, and no platform has a good story to tell. So XML is an obvious solution, right?

Applying XML at the database / application boundary involves retrieving XML from the database, then mapping this onto objects in the application layer. This results in an extra layer of abstraction and two mappings, where before we had one. Applying XML to the O/R mapping problem makes us i. transform relational data into XML, ii. transform XML data into objects.

This is a bad idea because the impedance mismatch between relational databases and objects is in no way addressed by introducing XML. We still have to make all sorts of messy decisions and kludges to get from one to the other. But twice.

But isn’t this abstraction useful when migrating to a new DB? I can’t speak from experience on this, but I suspect that O/R mapping is a pretty minor task compared to moving data and functionality between DBs, and the payoff will only ever occur during migration, but the penalty is ongoing.

Conclusion

XML is a big conspiracy to sell those high-end processors that have totally overshot the market. So I blame Craig Barrett.