May 2004 Archives

That's all, folks. I'm on vacation from tomorrow for two weeks. We gonna fly to Prague, stay there for some days and then make a car trip across Europe. No laptop. I'll read my mail occasionally though (I'm afraid otherwise my mailbox will explode with all that spam and I miss an important mail I'm waiting for).

That was a tough week for me. Sorry if I didn't answer some mails and didn't do what I promised. I still hope to provide unit tests for my classes in Mvp.Xml lib this evening.

See ya in two weeks. The June plans are huge. One more (in addition to Dimitre's one) pure (reflection-hacks-free) solution for returning nodesets from XSLT extension function problem, using XInclude with configuration files, next relase of XInclude.NET (update for the latest spec, support for intra-document references via in-memory mode), thread-safety and perf improvements for EXSLT.NET, next nxslt.exe with embedded XSLT profiler and XPath/XSLT analyzer, next WordML2HTML stylesheets, better asp:xml control and unveiling my new pet project (which is different from what I did before - it's UI oriented, but of course XML related). Thanks for reading and stay tuned.

From daily-bad-news department: "That's it for now" from xmlhack.com, a good news site for XML developers.

It's been a lot of fun writing XMLhack since 1999, but it's time for us to take a rest.

Every endeavour will be made to keep XMLhack content online at the same URLs for the foreseeable future.

And thirdly, never say never. We may return.

Michael Rys (PM for the SQL Server Engine support of XQuery) is trying to bring some order into the confusion around XQuery 1.0 and XPath 2.0 type system. His first instalment in the series introduces the terminology and general concepts. Read it here. More to come, worth to stay tuned.

Here is another piece of a must reading - "Chapter 9 - Improving XML Performance" of the "Improving .NET Application Performance and Scalability" guide from the Microsoft Pattern and Practices group. Here are the objectives : Optimize XML processing design, Parse XML documents efficiently, Validate XML documents efficiently, Optimize your XML Path Language (XPath) queries, Write efficient XSL Transformations (XSLT). Wow, amazingly good paper.

Here is interesting paper "XSLT and XPath Optimization" by Michael Kay. That's materials of Michael's talk at recent XML Europe conference. In this paper Michael reveals details of the XSLT and XPath optimizations performed internally by SAXON (XSLT and XQuery processor):

This paper describes the main techniques used by the Saxon XSLT and XQuery processor (http://saxon.sf.net/) to optimize the execution of XSLT stylesheets and XPath expressions, and reviews some additional XSLT and XPath optimization techniques that are not (yet) used in Saxon.

[Via XML.com]

Finally XPathReader has been unveiled at the MSDN XML DC in "Extreme XML: Combining XPath with the XmlReader" article by Dare Obasanjo and Howard Hao. Really, really interesting solution, alredy used in Biztalk internals to optimize XML pipeline processing. Need to play with it more.

I like XPathReader. It reminds me ForwardXPathNavigator and XSE. There is a real niche for streaming XPath querying - whenever one needs to query some value out of XML document without either writing potentially complex (hello state machine) XmlReader-based code or wasting resources loading the whole XML into memory. Streaming XPathReader is a perfect solution here. And limiting XPath here I believe is quite reasonable tradeoff. I hope some day XPathReader will make it to the System.Xml.
What I wonder to know though is what's behind the decision to augment XPathReader (which is XmlReader) by Match() an friends methods, which are traditionally associated with XPathNavigator? Why not implement standard XPathNavigator over XPathReader?

Additionally Dare created a GotDotNet workspace for the further development of the XPathReader and invited devs to join. I think XPathReader has a big future. Applied already.

Mono project (an open source implementation of the .NET framework for Linux, Unix and Windows) reached Beta1 stage. They say Mono 1.0 can be released this summer already.

Now to funny part. I've been reading Release Notes while downloading the release and found myself in the contributors list :) Well, in fact there are some classes in Mono codebase marked as created by me. But I should admit my contribution was really a small one - several patches, several trivial classes (in System.Xml.Xsl namespace) and then I lost my interest due to personal reasons. I still have write access to the Mono CVS, so may be, some day, who knows, again...

Daniel writes about transforming a portion of XML document using XPathNavigatorReader. That's a common bad surprise for MSXML-experienced people, who used to fooNode.transformNode() method, where only fooNode and its descendants are visible in XSLT. In .NET that's different - no matter which DOM node you pass to XslTransform.Transform() method, the whole XmlDocument tree is visisble in XSLT. MSDN suggests to load the portion of XML you want to transform into a temporary XmlDocument and pass it to the transformation. Too bad.

What Daniel proposes instead is to load the portion of XML to be transformed into a temporary XPathDocument instead of XmlDocument. Well, that's better, but what I'd like to ask is why do one need any temporary tree at all? It's a piece of cake to write custom XPathNavigator that would limit navigation only to a specified subtree. I did that once with XmlNodeNavigator, which represents XPathNavigator over XmlNode. Less than 10Kb of code. It's ideal solution to transform only a subtree of an XmlDocument. No temporary objects, just lightweight code between XmlDocument and XSLT that limits navigation not higher that specified node.

That's perfect for XmlDocument. For XPathDocument we need another one. Or better we need generic XPathNavigatorNavigator (did we really go nuts with these XML beasts?). XPathNavigatorNavigator should allow to navigate over given XPathNavigator, but should not allow to move it outside the subtree. Comments?

XPathNavigatorReader and XmlNodeNavigator are both parts of Mvp.Xml project.

I'm blogging sparely last time due to trivial lack of time. I'm taking two MVP academy courses (advanced C# and ASP.NET level 200) simultaneously, trying to catch up with what I've promissed for Mvp.Xml and XInclude.NET projects, preparing new article and working on my new pet project, which I'm going to unveil soon. Oh, and 9 hours of the day job too! Oh, I want a bit of vacation.

New version of the RSS Bandit has been released today. Amonst new features: support for Atom 0.3 support, ability to synchronize installations (killer!), 5 translations including Russian one made by me and lots more! Updated. Didn't check new features yet, but I can say the responsiveness is also improved!

This synchronizing feature is a real killer. I'm reading news from both home and work computers and now I can save huge amount of time having synchronized installations! That was so boring and depressing when I open RSS Bandit at home and needed to go through all feeds, thousands of items to see which I've read at work already and which I haven't. No more that silly waste of time, thanks to Dare and other members of the RSS Bandit team.

As Evan Lenz pointed out, O'Reilly put Chapter 2 ("The WordprocessingML Vocabulary") of the "Office 2003 XML" book online. Here it is (88 pages pdf). Excellent introduction to WordML. Those who want to learn WordML - go read it (or buy the book).

RenderX has announced the first release (somehow it's v3.0 :) of XEP.NET - XSL-FO formatter for .NET.

XEP.NET is a Visual J#.NET port of RenderX XEP, an XSL formatter for Java; its functionality and XSL FO support level are identical to the Java version. The XEP.NET core is wrapped in an API that exposes standard .NET interfaces for XML processing. This public API forms a .NET class library component that can be used from any .NET programming language: C#, VB.NET, or J#.NET. Additionally, the software includes a class library for MSXML integration that allows use of MSXML SAX parser and transformation APIs in addition to .NET system interfaces.

All editions include XEP.NET Assistant - a graphical shell to make formatting more convenient, and command-line tools for launching the formatter and the validator.