Newsletter April 2001

April Showers Bring .. Mud

April 13 2001

MSXML3 SP1 Released

There have been scattered reports that SP1 breaks SQL Server 7 installations. They seem to be unfounded. Testing on an unimportant computer may be prudent. If installed on a machine running SQL server, test remote access to the database server.

MSXML4 Preview is Available

MSXML4 supports XSD. Finally.

Download it here

XSLT Programmers Reference Second Edition Ready

The second edition of the XSLT Bible will be available any minute now.

MSXML3 Objects not Location-Independent

I thought I would share an issue I ran into MSXML3 this week that cost me $200 in support and about a day's worth of work.

The MSXML objects are not location-independent because they don't allow passing interface pointers across process boundaries. Indeed, I've even had problems passing interface pointers across apartments in the same process (using CoMarshalInterfaceInStream, etc.).

OK, sometimes it works but it's just a fluke. For instance, getting attributes, the "xml" property, etc. work fine across process boundaries. But you are bound to run into problems eventually, possibly after upgrading to a new version. At least that what the support people told me.

Here are two articles that describe the problem in more detail:

I came across this problem while attempting to transform a node that was from a different process. The transformNode method failed with E_INVALIDARG. When I ran the code in the debugger I discovered that MSXML3 was generating an access violation.

The solution is to pass the XML either as a string or a stream across the boundary, or use a file or URL.

I disagree with this "by design" behavior. The MSXML objects should support type library marshaling; that is, interface pointers are marshaled across apartments instead of the data. I don't want Microsoft to implement a custom marshaler that streams data behind my back because that could be extremely slow. Yes, the method call round trips require extra overhead. Let me make the decision whether to take the hit or not.

The work-around of passing strings or streams across process boundaries just doesn't work when this needs to be done frequently with large documents. It is too inefficient. Sometimes interface pointers are better, e.g., if you just want to get one attribute from one node or if you want to call transformNode (which happens completely on the server, resulting in only one round-trip) to execute a stylesheet against the document.

Again, let me make the decision whether to stream or not. I am capable of doing that based on my own requirements.

The DOM is a convenient container of data, like an ADO recordset, except much more powerful. It is useful in many contexts, not just in web document processing scenarios. It's nice not to have to define and implement custom interfaces when your data is just XML.

COM's location independence is desirable no matter whether you're talking to a local GUI component or to a remote XML object. It should not matter whether the MSXML components are called within the same apartment or across apartments, even across machine boundaries. That's what COM is all about.

I'm sure that Microsoft's XML engineers aren't stupid and they have a good reason for this behavior. It's probably to keep the implementation as fast as possible without using excessive amounts of memory. But these guys are brilliant and I'm sure they can fix this without losing performance.

Persistence Pays Off

Moved here