Rounding up some XML Team new blogs and posts

  • Article

You've seen Ralf Lämmel's post starting a series about our research and prototyping efforts to improve support for typed XML programming.  You might also wish to keep track of Ralf's weblog which will talk about these efforts in more detail as well as the diverse other things that are on his mind.  My favorite tidbit is his comparison of COBOL and XSD ... technologies that are scorned by the cognoscenti but adopted wholesale by the masses. There's even more intriguing stuff at his Amsterdam homepage.

Another team member with a (new?) blog is Anton Lapounov.  His post  XslCompiledTransform slower than XslTransform? summarizes what the XSLT team has learned about how to get the best performance with XslCompiledTransform, including:

  • Why XslCompiledTransform may start out slower than XslTransform
  • How to reduce start-up time if you use one of the managed XSLT processors
  • Why it is important to cache loaded XslCompiledTransform instances

I noticed that XML MVP Daniel Cazzulino has moved his blog to a new location. He's got a very interesting post on how LINQ allows strongly-typed reflection.  "The working principle is that lamda expressions passed as arguments (just as delegates in previous versions of .NET) are not necessarily executed."  I know that some people are not clear on why uber-geeky concepts such as lambda expressions -- essentially anonymous inline method definitions -- are being added to C# 3.0, so it's great to see such a clear explanation of what they are and how they can be used to greatly increase the power of the language at relatively little cost in complexity.

Finally, I'll put in a shameless plug for my post on the "Halloween Problem" as it applies to APIs (including DOM and especially XLinq) that provide both lazy queries / iterators for locating data and imperative methods for manipulating it.  This is one of those things that is simple in concept ("if you change the members of the set defined by a query in the middle of executing the query, strange things are going to happen!"), but it's implications are subtle and non-obvious to most of us.  I'm not exactly sure that this is what database people mean by the Halloween Problem, but it's the label we use on the XLinq team for a whole class of interesting bug reports from both XLinq testers and DOM customers.  This post only scratches the surface, but I hope it gets people thinking about a problem that I hadn't heard of until I joined the XLinq team. 

Mike Champion