Wow. I'm a bit suprised at the vehemance in Dare'sresponse to Ted's article on strongly-typed infosets. Having read it,I still think I side with Ted (not my opinion really matters in thegrand scheme of things! :) ) 

First off, Dare makes a point about how Ted's approach requires "modifying your classesto subclass DOM nodes". That's not necessarily true -- the objects that would naturallyimplement this pattern are primarily Data Transfer Objects (ref Fowler, Patternsof Enterprise Application Architecture), not logic components that operateon that data. I think it makes sense to keep data that came in to the system as XMLin some sort of XML representation, instead of compeletely mapping it over via a non-isomorphictransform to the object domain. Especially since you're probably just going to endup doing the reverse on the way out of the system. This XML-to-object conversion overheadis expensive (although I'm not sure how it compares with parsing data into a DOM --there's an opportunity for an interesting cost comparison here).

Dare suggests using an ObjectXPathNavigator as an alternative solution. This approachlets you achieve the goal of leveraging XPath as an query mechanism, but it stilllocks you into an object-oriented closed content model. I think that there's a lotof elegance in Ted's approach becuase it makes dealing with open and extensible contentmodels very simple. I don't think ObjectXPathNavigators are very resilient in theface of unexpected context. Additonally, handling nested complex types with an ObjectXPathNavigatoris complex and in fact not implemented in the version out on MSDN. Additionally, theimplementation of ObjectXPathNavigator referencedon MSDN looks to be rather memory intensive, although I have no hard data asto how it compares to the XmlDocument. Again, this would be an interesting cost comparison.

I'm not even going to touch the namespaces-as-versioning-mechanism until I watch DougP'spresentation a couple of more times, but my gut says that the versioning problemshould be a lot simpler than we try to make it.