Doug's series of articles on the appropriately named "SlashDot" problem provide a very interesting look at how people want to interact with XML and XML-based technologies. The Slashdot Problem is the fact that people want dots over XML (i.e. once parsed access XML elements and attributes as if they were the fields or properties of an object) and also want to treat objects like XML (i.e. hence utilize XML technologies like XPath for querying). One can get the former in the .NET Framework via XML Serialization and the latter via custom XPathNavigator's like Steve Saxon's ObjectXPathNavigator
The only nit I have to pick with Doug's series is that in part 3 he doesn't show how using XPath to access objects is any better than directly accessing properties. Steve Saxon nailed it in his guest appearance in my column that it is all about the ability to perform complex queries over object graphs.
The interesting perspective from Doug's series is that providing some of this functionality in a dynamically typed language is actually far easier than doing it in a statically typed one. Of course, there are a number of issues in part 2 that Doug doesn't get into such as how to deal with XML namespaces or how to get around the fact that SmallTalk is strongly typed. Given that this was a blog post and not an actual technical article or a paper I didn't expect Doug to exhaustively cover the topic but I would love to see his ideas on how to deal with either of those issues.
Harry Pierson is on the road to XML Zen. However he has some misconceptions. The first is that he states
Given an object graph, I can serialize it into XML and then deserialize it into an identical object graph. However, I don't think I can take an arbitrary XML document and always be able to deserialize it into an object graph.
The bigger misconception I'd like to clear up is
XML concepts like derivation by restriction are difficult to model in a strongly typed object model like CLR's
Since between Joshua and I lies responsibility for the current and future XML programming model for the .NET Framework this is something I'd like to officially address with some sort of best practices document or white paper. All the feedback in the discussion threads is stuff that I've noted and will try to ensure that we try to address in the next release of the .NET Framework.
Until then this post by Justin Rudd is a must-read for anyone who is considering working with the .NET Framework and considering how to pass XML between application layers.
Overall, I liked the theme of this post but there were a number of specifics I took issue with. For instance he says
The problem with the hierarchical model at the time was that attempting to find data within it was difficult, since users had to navigate the elements of the tree manually, leaving users to figure out "how", instead of focusing on "what"--that is, how to get to the data, rather than what data they were interested in.
I also like
While the industry currently doesn't recognize it, the mapping of objects to XML (the most common hierarchical storage model today) is not a simple thing, leading one to wonder if an object-hierarchical impedance mismatch is just around the corner*.