I’m sure this is going to get blogged almost immediately, but I’ll just add my two cents here - Microsoft has formally announced that with the publication of the XSLT 2.0 Recommendation the XML Team has commenced working on a new XSLT 2.0 implementation that will be available as part of the .NET platform, with the very real possibility that it will also be folded into the Internet Explorer browser. This is fantastic news, and will make XSLT 2.0 adoption move considerably more quickly than I had feared it might. Kudos go to Mike Champion and the MS XML Team … and I know I can hardly wait to try it out.
> with the very real possibility that it will also be folded into the Internet Explorer browser.
While I was aware of the XSLT 2.0 support (http://www.oreillynet.com/xml/blog/2007/01/i_heart_xml_team.html), I thought, for a second, that maybe you had given in and started smoking some of our neighbor to the north's finest, but no, in fact,
We are discussing whether to implement XSLT2 in the native stack (MSXML3 and MSXML6). The needs of IE are the biggest consideration (it uses the native libraries), and we will definitely coordinate with the IE team.
Holy Hannah! Okay, so multiple output doesn't make a lot of sense in the browser-based world, but beyond this, there is very little to nothing that I can see that wouldn't ROCK if we had access to the rest of the functionality via MSXML and, as such, IE.v.Next();
SWEET!!!
I suppose multiple output documents could be mapped to special URIs for use in frames or IFRAMEs. I recall wishing that were possible in years past, but I don't remember what the context was.
This is very good news! Whatever personal views may be concerning IE, Microsoft's stamp of approval is still worth a great deal... and I've personally found the effects of XSLT 2 to be psychologically, if not physically addictive. There are a lot of MSXML users who just haven't tried it yet...
Hi Evan!
Multiple document output comes in handy in a limited number of situations on the client such as being enable posting of XML content to the server directly from the stylesheet. It's not a perfect solution, because there is no way to attach handlers to catch the returning response content (and its an asynchronous call), but its good for logging or similar activity. Of course, if extensions are supported (and no doubt they will be), it's more likely that these web services calls will be handled through some other process instead (passing in JScript event listeners as recipients for posted content outside of the content of the current XSLT process, for instance).