May 10, 2005

.NET XSLT API - broken again?

.NET XSLT API is traditionally ugly. XslTransform class (obsoleted in .NET 2.0) had 8 Load() methods and 9 Transform() ones in .NET 1.0. In .NET 1.1 - 11 Load() methods (5 of them obsoleted) and 18 Transform() (9 obsoleted). Huge mess. Brand new XslCompiledTransform in .NET 2.0 Beta2 has just ...

For instance there is no Transform() method that accepts IXPathNavigable and XmlResolver. That means one can't transform already loaded XmlDocument or XPathDocument and provide XmlReader instance (say with user credentials set) at the same time. The only workaround is to pass XmlReader over XmlDocument or XPathDocument, which means ridiculous thing - I've got loaded XPathDocument, but have to pass an XmlReader over it so XslCompiledTransform will build another temporary copy of this XPathDocument. What a waste of memory!

Another uncovered case - the only Transform() method accepting XmlResolver outputs to an XmlWriter. But what if I transfrom to HTML or text? There is no workaround here.

Why this stuff is so complicated? The core problem is that input and output of an XSLT processor can be of a variety of forms. Generally speaking XSLT input can be string (document URI), Stream, TextReader, XmlReader or IXPathNavigable. And output can be string (URI), Stream, TextWriter or XmlWriter. 5 times 4 = 20. Plus optional XsltArgumentList and optional XmlResolver - 20 times 2 times 2 = 80 Transform() methods for the maximum usability. That's of course crazy. Encapsulation usully helps. Stream can be encapsulated into TextReader and TextReader into XmlReader and XmlReader into IXPathNavigable. Output isn't so easy. Stream, TextWriter or XmlWriter arte really needed. And recall usability... So it's still to many methods.

I wonder if the XML Team considered javax.xml.transform.Result approach?