October 2005 Archives

Norman Walsh:

In any event, after much procedural wrangling, the W3C has finally chartered a new Working Group in the XML Activity to address the problem of a standard XML pipeline language, the XML Processing Model Working Group. And they persuaded me to chair it, for better or worse. :-) The charter lays out the scope, goals, and deliverables pretty well, so I won't bother recapitulating them here.

I'm migrating lots of code to the .NET 2.0 nowadays and wanted to warn my readers about one particularly nasty migration issue. When moving from Hashtable to Dictionary<K, V> look carefully at the indexer usage - there is a runtime breaking change here. With Hashtable when you do myhashtable[mykey] and myhashtable doesn't contain mykey you just get null. But Dictionary<K, V> in this case throws KeyNotFoundException! This is of course not due to the evil will of Microsoft, but because unlike Hashtable, Dictionary<K, V> can store not only reference but value types too, so null is not an option anymore. Read a discussion at Brad Abrams's blog for more info about how this shit happened.

Another minor nxslt release is available - v1.6.4. This version adds support for the "extension-element-prefixes" attribute and fixes a glitch in transformation timings reporting.

What's the problem with "extension-element-prefixes" attribute? When using <exsl:document> extension element to produce multiple outputs some EXSLT-aware XSLT tools (like 4XSLT) rightly require "exsl" prefix to be registered in the "extension-element-prefixes" attribute. The problem was that .NET's XslTransform class while not supporting extension elements at all, throws an exception once encountering "extension-element-prefixes" attribute. So for running the same stylesheet with nxslt one had to remove "extension-element-prefixes" attribute, and with other tools - add it. Bad bad bad. So in nxslt 1.6.4 I fixed the issue by hiding "extension-element-prefixes" attribute from XslTransform class, so now you can use it in you stylesheets and enjoy better portability.

As a matter of interest, new .NET 2.0 XSLT processor - XslCompiledTransform class, while still not supporting extension elements, at least ignores "extension-element-prefixes" attribute. Good.

Microsoft put hundreds of hours PDC 2005 videos online at http://microsoft.sitestream.com/PDC05. Here is a list of XML-related and others interesting presentations worthwhile watching IMHO.

Opera 9.0 Preview 1 released October 20 finally adds support for XSLT and XPath to the Opera browser. Finally they are awake. Good move, but it might be too late for the Opera.

[Via <XSLT:Blog/>]

I've seen this video at the MVP Summit. Fun, but you know, sometimes I wish something like that was actually deployed. Hey, wait, I'm a developer too... Well, all actions have consequences after all.

Oh, and don't forget "Bill Gates goes to college" too.

What I can't find on the net is a very fun picture of Erik Meijer "unveiling XML literals in VB9 to the world". That's probably still NDA photo :)

Interesting - during last month both leading XML hardware makers - DataPower and Sarvega were acquired - former by IBM and latter by Intel. Both sites have almost similar "We are acquired!" announcements.

I'm disappointed in ASP.NET once again. I was building some ASP.NET 2.0 application with XSLT processing involved, run into XSLT bugs and oh horror realized the ASP.NET 2.0's asp:xml server control still uses old slow as hell buggy obsoleted deprecated XslTransform class! That more than sucks. That's no use. I just stop using asp:xml control and won't recommend to anybody using it. I just can't understand how come one Microsoft group spends years to build a better tool and then another Microsoft group, which uses the tool, just ignores it and keeps using old obsolete one. Something is wrong here.

Ward Cunningham leaves Microsoft to work for The Eclipse Foundation. Wow.

I was always sure that's what Haskell desperately needs: Visual Haskell:

Visual Haskell is a complete development environment for Haskell software, based on Microsoft's Visual Studio platform. Visual Haskell integrates with the Visual Studio editor to provide interactive features to aid Haskell development, and it enables the construction of projects consisting of multiple Haskell modules, using the Cabal building/packaging infrastructure.

Don Box said "Scheme Is Love", but he forgot to mention that Scheme is actually Love to Lots of Irritating, Silly Parentheses. Haskell my friends is the Real Love.

[Via Lambda the Ultimate]

Norman Walsh:

XML Catalogs V1.1 is an OASIS Standard.

I'm also happy to report that my implementation of XML Catalog support, currently part of the xml-commons project at Apache, will ship as a standard part of the next Java™ release.

You've got a standard. You've got an implementation. What are you waiting for? I've been using catalogs for at least ten years, and XML Catalogs for at least five, so really, you can start deploying them today.

If you have tried to create or use code snippets in any of XML languages in Visual Studio 2005 you probably stumbled across the issue of using shortcuts. In C# or VB you just type code snippet's shortcut name and press Tab, it just works. In XML it doesn't :(. I've spent couple of hours reflecting into XML editor to see why it doesn't work (that was an interesting waste of time anyway) and when I just found out how it works I also found out (via Aaron Skonnard) it's documented at MSDN. RTFM, RTFM, RTFM.

Unfortunately inserting code snippets by shortcut name in XML editor of Visual Studio 2005 isn't as smooth as in C# or VB. Two more keystrokes: < and Esc. So press <, Esc, then shortcut and then Tab. That sucks, but I can live with it.

In .NET 2.0 ValidationType.Auto value is made obsolete. What's worse - it doesn't work for XmlReaders created via XmlReader.Create() factory method. But how do you validate against either DTD and/or schema, i.e. against DTD if document has a DOCTYPE and/or schema if any is applicable? The answer is: you can chain two XmlReaders, one set up for performing DTD validation and second - schema validation.

Microsoft XML Team has published an article "Migrating to XslCompiledTransform" by my pals Sergey Dubinets and Anton Lapunov. It explains how to migrate to the new XSLT 1.0 processor in .NET 2.0 - XslCompiledTransform class. XslCompiledTransform is a revolutionary XSLT processor - it's gonna be the first truly compiled mainstream XSLT processor. It's fast and conformant just as MSXML4.

The article covers: how XslCompiledTransform works, differences in API, in behaviour, new functionality, faq, howto.

The article is meant to be updated on a regular basis. Once a new migration issue is discovered the article will be updated with a solution. So bookmark it. And the article is not complete yet, some parts are still to be done. Keep up your great work, guys.

nxslt 1.6.1 is available for download at the xmllab.net. This is bug fix only release. Marc Stober reported that when running into XInclude error he got MissingManifestResourceException. Apparently XInclude string resources weren't compiled into the nxslt.exe. This release fixes this bug. Thanks for reporting, Marc!

nxslt is free feature-rich command line .NET XSLT utility, supporting EXSLT.NET, XInclude, multiple output etc etc etc.

No new features in this release. Instead I'm working on nxslt2 - nxslt for .NET 2.0.

I've been looking for a blog search service and been naturally inclined to use Google blog search, but I was quite disappointed to find out that feeds produced by Google are malformed. Trivial lame mess with encoding, hence no use by XML tools. Apparently XML is too hard for Google. Oh well, at least Technorati sucks less.