Hmmm, debugging XSL-FO... That might be great idea actually. Here is interesting innovation from Altsoft N.V. (maker of the Xml2PDF formatting engine for .NET) - XSL-FO debugger. And it's even free!
...
I wonder if is there is something inherently wrong with XslTransform's class API? I was stunned again today reading this post in microsoft.public.dotnet.xml newsgroup: I still don't see any way to create a XslTransform from a XmlDocument? That's not the first time I see it actually. The answer of course
...
Kenny Kerr has posted another instalment in his amazing "Introduction to MSIL" blog series. It's about brilliant for-each construct, which was introduced by Visual Basic and now adopted by VB.NET, C#, C++ and even Java. Worth reading. Besides I very like that idea of learning from blogs - you know
...
That guy Loren Halvorson has relased XmlPreprocess tool for preprocessing XML files, e.g. config files in .NET. It allows to perform the following tricks: <configuration> <system.web> <!-- ifdef ${production} --> <!-- <compilation defaultLanguage="c#" debug="false"/> --> <!-- else --> <compilation defaultLanguage="c#" debug="true"/> <!-- endif --> </system.web> </configuration> As you can see
...
I was doing some catch up reading feeds I'm subscribed and I found this one item that made me feeling some sort of bitter nostalgia. It's right on MSDN TV site, a new episode where Mark Fussel explains new XML features in upcoming .NET 2.0. The episode is dated December
...
Mark is very energetic guy and nicely talks about editable XPathDocument as a preffered XML store in .NET2 (has been cut, stick with DOM for several more years) and of course XQuery implementation in .NET2 (cut). So basically all new XML features that still not cut are about performance, some API rearranging and XSLT 1.0. Performace was an old pain and had to be fixed anyway. XSLT 1.0 stuff is good - finally XSLT debugger (which actually was hidden as internal stuff within System.Xml.dll since .NET 1.0 - just run Reflector to see it), better XML and XSLT editor in Visual Studio .NET 2005, and brand new XSLT 1.0 processor, which compiles XSLT down to MSIL - this one is just perfect and I'm looking forward to give it a whirl. So as a matter of curiosity .NET 2.0 is going to include two different XSLT 1.0 processors (one obsoleted though).
Well, I'm not saying that's nothing. But let me be harsh - it's all catch up stuff. It would be excellent to have in .NET 1.1, but for year 2005 it's quite disappointing. May be that's because all that hype about XQuery and how it's better than XSLT. There were really hot debates on Microsoft decision to implement XQuery, but not XSLT 2.0 and now guess what - neither XQuery nor XSLT2.0 and developers running out.
I can imagine how much resources have been spent on XQuery! That's not a small one. Apparently managed XQuery turned out to be just another black hole project. Who knew, right?
Oh well, there is Saxon.NET and may be will be XQP. But I fell a little bitter taste when I realize I'll still be helping people struggling with XSLT 1.0 limitations at least next 3 years, while XSLT 2.0 is shining in a better world. And my fellow XML MVPs are sharing my feelings. Still - what a sad irony - to listen to Mark, who has left XML team talking about XQuery impementation, which was cut...
Some goodies from Daniela Florescu and the Database Group at the University of Heidelberg: "The BEA Streaming XQuery Processor" (full version?), D. Florescu, C. Hillery, D. Kossmann, P. Lucas, F. Riccardi, T. Westmann, M.J. Carey, A. Sundararajan. VLDB Journal. "Implementing Memoization in a Streaming XQuery Processor", Y. Diao, D. Florescu
...
This is amazing. Adam Kinney (Xamlon guy) runs his new blogsite on XSLT 2.0 (using Saxon.NET as XSLT engine): Adam Kinney.com has been redesigned, restructured and refactored. The new site has been inspired by my hate fo comment spam, interest in XSLT 2.0, desire to lose SQL and move to
...