October 24, 2006

Free Brainbench Certification

Just in case somebody needs is: Brainbench is giving away some certification tests for free. Including:

Beware that "Free certification tests do not include a hardcopy certificate, but are included in your online transcript."

Back in 1999 I had lots of Brainbench certificates. They were all free and so that was sort of cool game - they were keeping top list with high scores for each test and the goal was to be the first in that list. Dunno if Brainbench is still doing this but that sort of competition was really great idea.

October 15, 2006

xsl.info xpath.info domains

I still own xsl.info and xpath.info domain names and still have no time to build anything around there. If anybody have any ideas about any community driven projects - let me know, I'm willing to donate domain name and may be participate.

And if anybody want to buy these domain names - I'm willing to sell.

October 13, 2006

.NET XmlReader API flaw

.NET's XmlReader is a great XML parser, but it has one big flaw in its API: XmlReader doesn't expose attribute types. XML actually defines 8 attribute types: CDATA, ID, IDREF, IDREFS, ENTITY, ENTITIES, NMTOKEN, NMTOKENS. Yes, it's DTD, which apparently Microsoft considers to be dead,  but ID, IDREF, IDREFS types are really important ones. They provide support for cross-references and many XML languages rely on them, particularly XPath, XSLT, XQuery, XPointer, XInclude.

That means XmlReader cannot be used to develop third-party implementations of those languages unless one sticks to XPathDocument/XmlDocument, which know attribute types internally.

I wonder if XLinq will have this information, because if not - XSLT over XLinq won't be supporting id() function.

Btw, in Java SAX and Stax both happily expose attribute types... Makes me envy.

I though I filed it as a bug years ago, but I didn't. So although it's too late, here it is. I'm sure it will be another "thanks for suggestion, we'll consider it for the next release", but anyway. Vote please whoever cares.

October 12, 2006

XSLT scripting (msxsl:script) in .NET - pure fast evil

Another coding horror story was reported in the microsoft.public.dotnet.xml newsgroup:

I've been experiencing OutOfMemory errors on our prodution webserver for a few weeks now. I've finally managed to isolate (I think) the problem to our use of c# script blocks in our xsl files.
While debugging I discovered that the app domain for one of our sites had 13000+ assemblies loaded.

Cool. This is just a remainder for those who use XSLT scripting (msxsl:script) in .NET: watch out, this feature can be pure evil if used unwisely - it leaks memory and there is nothing you can do about it.

The problem is that when XSLT stylesheet is loaded in .NET, msxsl:script is compiled into an assembly via CodeDOM and then loaded into memory, into the current application domain. Each time the stylesheet is loaded above process is repeated - new assembly is being generated and loaded into the application domain. But it's impossible to unload an assembly from application domain in .NET!

Here is KB article on the topic. It says it applies to .NET 1.0 only, but don't be confused - the problem exists in .NET 1.1 and 2.0. Moreover I'm pretty much pessimistic about if it's gonna be fixed in the future.

The solution is simple - just don't use script in XSLT unless you really really really have to. Especially on the server side - XSLT script and ASP.NET should never meet unless you take full resonsibility for caching compiled XslCompiledTransform. Use XSLT extension objects instead.

Update. Of couse Yuriy reminds me that msxsl:script runs faster than an extension object, because msxsl:script is available at compile time and so XSLT compiler can generate direct calls, while extension objects are only available at run-time and so can only be called via reflection.

That makes msxsl:script a preferrable but danger solution when your stylsheet makes lots of calls to extension functions.

In a perfect world of course msxsl:script would be compiled into dynamic methods (just like XSLT itself), which are GC reclaimable, but I don't think CodeDOM is capable of doing this currently. I wonder if it's possible to compile C#/VB/J# method source into dynamic method anyway?

Also it's interesting how to improve extension objects performance - what if extension objects could be passed at compile time? They are usually available anyway at that time too. Or what if compiled stylesheet could be "JITted" to direct calls instead of reflection?

Sergey, Anton, can you please comment on this?

October 3, 2006

Joe Fawcett is blogging

Joe Fawcett, XML expert and my fellow XML MVP  has started a blog. Highly recommended. Subscribed.