More Namespaces under Construction

The last few days witnessed unprecedented progress in this years-long migration from COM goop to .NET OOP. The chamber is loaded and here are the water-tipped bullets:

Submitting InfoPath forms to a Web Service

• The first goal is to design forms for data entry—not for data editing. This decision allows me to focus on getting something done InfoPath instead of being intimidated and overwhelmed by its simplicity and ease of use.
• The second principle is to “loosely couple” the schemas of the DBMS with the schemas of a given form. In fact, the conceptual breakthrough for me was to open InfoPath and build a schema to get the job done for the form—instead of trying to match a schema outside of the form—which was a crazy idea in view of the fact that InfoPath XML cannot be ‘trusted.’
• The third revelation was to put the XPathNavigator rants of Don Box in perspective and simplify the relationship InfoPath has with a Web service. The simple relationship is this: send the whole, damn, XML document to the Web service! More specifically, send the root element to a Web method that accepts values of type XmlDocument—why not an XPathNavigator object? The answer is simple: XPathNavigator can’t be serialized—and who knows what the InfoPath team thinks of Don Box and his one true love.

Responding to the Guidance of Don Box

• First of all, he was talking about passing around data in a .NET application domain. InfoPath is mired in COM goop.
• Second, he was concerned about loading an entire XML document into memory, which can seriously impact performance. An InfoPath form should never, ever have as much XML as a phone book composed in Frame Maker or a 1500-page technical manual in DocBook format.
• Third, the implication is that he was not concerned about validation and I am pretty sure that XPathDocument types do not provide validation—because validation requires loading the whole damn document into memory.
• Finally, Don Box reminds us that we can obtain an XPathDocument object from the XmlDocument object using the CreateNavigator() method—which to me is a slamming compromise when the time comes to read data out of the incoming XML document.

More Understanding for Collections

• What appears to be apparent is that it is useful to divide collections in .NET 1.x into two general classes: list-style collections and name-value pair collections. For folks from the VB6/VBA world, a list-style collection would be an Array and the name-value pair collection would be the Dictionary—this can roughly translate into collections that derive from IList and those that derive from IDictionary, respectively (all interface with the ICollection of course).
• For old-school ASP developers turned .NET developers, the problem of populating an HTML “combo box” (or select list)—without the ‘benefit’ of ASP.NET data binding—should lead them to the .NET name-value pair collection SortedList. Why not the Hashtable type? The answer is simple: the Add() method of the Hashtable type loads in random order (probably for performance reasons). There are legends of people sorting hash tables and I am sure they are cool and stuff but…
• Sune Trudslev has a noisy pub rant about .Net Collections worth a stare at CodeProject.com. He reminds me that BitArray, Queue and Stack are not derived from either IList or IDictionary—not name-value pairs but interesting nonetheless. And, oh, Mike McPhail’s Hashlist thing is interesting too.

rasx()