March 17, 2004

Transforming WordML to HTML: Support for Images

Update: this post is outdated, see "WordML2HTML with support for images stylesheet updated" for updates. Here is a new version of WordML2HTML XSLT stylesheet, developed by Microsoft for Word 2003 Beta2 and adapted by me to Word 2003 RTM. I called this version "1.1-.NET-script". Here is why. Along with some ...

Word 2003 allows to save document as "Single File Web Page" (*.mht aka Web Archive file) or as usual HTML document. In the latter case all images embedded into Word document are saved into documentName_files directory. Here is a challenge - how to implement it with XSLT. Obviously we need extension function to decode (Base64) embedded image and to write to a directory. That's not a big deal, but the problem is it makes XSLT stylesheet not portable, that's why I need different versions for .NET, MSXML etc. Second problem - WordML document doesn't store name of file, so the question is how to name a directory where to save decoded images. I introduced a global stylesheet parameter called docName to facilitate the issue. If docName parameter isn't provided, it's defaulted to first 10 characters of the document title.

To run the transformation I used nxslt.exe command line utility. Download it for free if you don't have it yet.

So I created test Word 2003 document with a couple of images:
Test Word document with a couple of images
Saved it as XML to test.xml file and run transformation to HTML by the following command line:

nxslt.exe test.xml d:\xsl\Word2HTML-.NET-script.xsl -o test.html docName=test
As the result, XSLT transformation created test.html document and test_files directory, containing two decoded images, here is how it looks like in a browser:
Word document transformed into HTML.

The implementation is very simple one. Here it is:

<msxsl:script language="c#" implements-prefix="ext">
  public string decodePicture(XPathNodeIterator bindata, string dirname, string filename) {
    if (bindata.MoveNext()) {
      System.IO.DirectoryInfo di = new System.IO.DirectoryInfo(dirname);
      if (!di.Exists)
        di.Create();
      using (System.IO.FileStream fs = 
        System.IO.File.Create(System.IO.Path.Combine(di.FullName, filename))) {
        byte[] data = Convert.FromBase64String(bindata.Current.Value);
        fs.Write(data, 0, data.Length);
      }
      return dirname + "/" + filename;
    }
    else 
        return "";
}
</msxsl:script>
<xsl:template match="w:pict">
  <xsl:variable name="dir">
    <xsl:choose>
      <xsl:when test="$docName != ''">
        <xsl:value-of select="$docName"/>
      </xsl:when>
      <xsl:otherwise>
        <!-- We need something unique instead of document name -->
        <!-- Let's take first 10 characters of title -->
        <xsl:value-of select="translate(substring($p.docInfo/o:Title, 1, 10), ' ', '')"/>
      </xsl:otherwise>
    </xsl:choose>
    <xsl:text>_files</xsl:text>		
  </xsl:variable>
  <img 
  src="{ext:decodePicture(w:binData, $dir, substring-after(w:binData/@w:name, 'wordml://'))}" 
  alt="{v:shape/v:imagedata/@o:title}" style="{v:shape/@style}" 
  title="{v:shape/v:imagedata/@o:title}"/>
</xsl:template>
Not a rocket engineering indeed. Yes, Sal, WMZ images are not supported, I have no idea how to convert them to GIF.

Download the stylesheet here and give it a shot. Again - this stylesheet requires .NET XSLT engine. Any comments/requests/bug reports are welcome.

March 16, 2004

XML Bestiary: IndexingXPathNavigator

Here I go again with another experimental creature from my XML Bestiary: IndexingXPathNavigator. This one was inspired by Mark Fussell's "Indexing XML, XML ids and a better GetElementByID method on the XmlDocument class". I've been experimenting with Mark's extended XmlDocument, played a bit with XPathDocument and "idkey()" extension function Mark ...

Intro

IndexingXPathNavigator is a wrapper around any XPathNavigator, augmenting it with indexing functionality. Such architecture allows seamless indexing of any IXPathNavigable XML store, such as XPathDocument, XmlDocument or XmlDataDocument. The overall semantics behind should be very familiar to any developer acquainted with XSLT as IndexingXPathNavigator behavior literally follows XSLT 1.0 specification.

The main scenario when IndexingXPathNavigator is meant to be used is uniform repetitive XPath selections from loaded in-memory XML document, such as selecting orders by orderID from an XmlDocument. Using IndexingXPathNavigator with preindexed selections allows drastically decrease selection time and to achieve O(n) perf.

How it works

First one have to declare keys, according to which the indexing occurs. This is done using
IndexingXPathNavigator.AddKey(string keyname, string match, string use) method, where
keyname is the name of the key,
match is an XPath pattern, defining the nodes to which this key is applicable and
use is an XPath expression used to determine the value of the key for each matching node.
E.g. to index XML document by "id" attribute value, one can declare a key, named "idKey" as follows: AddKey("idKey", "*", "@id"). This method works identically to XSLT's <xsl:key> instruction. Essentially a key can be thought as a collection of node-value pairs. During indexing IndexingXPathNavigator builds a Hashtable for each named key, which contains nodes and associated values and allows to retrieve nodes by key value. You may define as many keys as you need including keys with the same name.

After all keys are declared, IndexingXPathNavigator is ready for indexing. Indexing process is performed as follows - each node in XML document is matched against all key definitions. For each matching node, key value is calculated and this node-value pair is added into appropriate Hashtable. As can be seen indexing is not a cheap operation, it involves walking through the whole XML tree, multiple node matching and XPath expression evaluating. That's the usual indexing price. Indexing can be done in either lazy (first access time) or eager (before any selections) manner.

After indexing IndexingXPathNavigator is ready for node retrieving. IndexingXPathNavigator augments XPath with standard XSLT's key(string keyname, object keyValue) function, which allows to retrieve nodes directly from built indexes (Hashtables) by key value. The function is implemented as per XSLT spec.

Usage sample

Here is common usage pattern, which I used also to test the performance of the IndexingXPathNavigator. There is an XML document, northwind.xml, which is XML version of the Northwind database. It contains lots of orders, each one consisting of order ID, order date and shipping address:
<Item>
  <OrderID> 10952</OrderID>
  <OrderDate> 4/15/96</OrderDate>
  <ShipAddress> Obere Str. 57</ShipAddress>
</Item>
The aim is to select shipping address for an order by order ID. Here is how it can be implemented with IndexingXPathNavigator:
XPathDocument doc = new XPathDocument("test/northwind.xml");
IndexingXPathNavigator inav = new IndexingXPathNavigator(
  doc.CreateNavigator());
//Declare a key named "orderKey", which matches Item elements and 
//whose key value is value of child OrderID element
inav.AddKey("orderKey", "OrderIDs/Item", "OrderID"); 
//Indexing
inav.BuildIndexes();
//Selection
XPathNodeIterator ni =  nav.Select("key('orderKey', ' 10330')/ShipAddress");
while (ni.MoveNext())
  Console.WriteLine(ni.Current.Value);

Performance test

Here are results of my testing. northwind.xml is 240Kb and contains 830 orders. I'm searching shipping address for an order, whose OrderID is 10330 (it's almost in the middle of the XML document) using regular XPathNavigator and IndexingXPathNavigator (code above, full code in the download). My PC is 533MHz/256M RAM Win2K box, here are the results:
Loading XML document: 167.12 ms
Regular selection, warming...
Regular selection: 1000 times, total time 5371.79 ms, 1000 nodes selected
Regular selection, testing...
Regular selection: 1000 times, total time 5181.80 ms, 1000 nodes selected
Building IndexingXPathNavigator:   1.03 ms
Adding keys:   5.16 ms
Indexing:  58.21 ms
Indexed selection, warming...
Indexed selection: 1000 times, total time 515.90 ms, 1000 nodes selected
Indexed selection, testing...
Indexed selection: 1000 times, total time 476.06 ms, 1000 nodes selected
As can be seen, average selection time for regular XPath selection is 5.181 ms, while for indexed selection it's 0.476 ms. One order of magnitude faster! Note additionally that XML document is very simple and regular and I used /ROOT/CustomerIDs/OrderIDs/Item[OrderID=' 10330']/ShipAddress XPath for regular selection, which is almost linear search and is probably the most effective from XPath point of view. With more complex XML structure and XPath expressions such as //Item[OrderID=' 10330']/ShipAddress the difference would be even more striking.

Download

I wanted to make IndexingXPathNavigator a subproject of MVP XML library, but failed. I forgot I can't work with CVS over SSH from my work due to closed SSH port. Grrrmm. Ok, after all it's experimental implementation. Let's see if there will be any substantial feedback first.

Full source code along with perf testing. As usual two download locations available: local one and from GotDotNet (will update later). IndexingXPathNavigator homepage is http://www.tkachenko.com/dotnet/IndexingXPathNavigator.html.


I really like this one. Probably that's what my next article is going to be about. What do you think? I'm cap in hand waiting for comments.

MovableType 3.0 on the horizon

Here is what MovableType blogging engine team writes: We're taking our first steps towards the release of Movable Type 3.0. The pre-beta version has just finished its initial two rounds of alpha testing and we're now opening the testing to a larger audience ... What's new includes: "significant change to ...

RE: Changes in the Workspaces releases area

Hey, good news about GotDotNet Workspaces again! Changes on the releases section scheduled for tomorrow include: per-release download count (AT LAST!!!), no more zero-byte/corrupt downloads (I hope), no more Passport sign-in for downloads (great), off-site hosting of releases (cool). Really sweet. [Via Andy Oakley] ...

March 14, 2004

ASP.NET XML syntax?

XAML, Windows Forms Markup Language (WFML), Report Definition Language (RDL), Relational Schema Definition (RSD) and Mapping Schema Definition (MSD). You get the idea what the trend is nowadays. It's all XML. What I'm wondering though - why still there is no alternative ASP.NET XML-based syntax? How long ASP.NET will stay ...

RE: Opera As An RSS Reader

Hey, apparently recent Opera browser beta has RSS reader embedded. Here are some screenshorts - here and here. I like that trend. [Via 10x More Productive Blog] ...