XSLT is an XML application so why not transform it

As it happens, Michael Kay is presenting a paper entitled Meta-stylesheets at XML2006.

It must be about three years ago that I had what can only be described as an epiphany with respect to seeing XSLT for what it is, an XML application and as such can be generated by XSLT and for that matter transformed by XSLT into another XSLT.

If you are using a framework like Apache's Cocoon, that allows XSLT transforms to be referenced as the product of another pipeline then that's one way to employ meta-stylesheets. Another and potentially more interesting approach, which I'm sure Mr. Kay will bring-up, is the use of the Saxon 8 / XSLT 2 extension functions saxon:compile-transform() and saxon:transform(). These two together allow you to load a stylesheet into your running stylesheet and apply it to a node-set or sequence that you are working on.

But why stop there when you could build a transform at run-time based on some aspect of your source document then apply that transform to either the source or some node-set derived from the source to produce the desired result.

All very wonderful stuff and I'd love to be there when he presents his paper but alas I will not. So I hope it will be available post conference in some way shape or form.

I initially used XSLT transforms on XSLT stylesheets to map some XHTML generating XSLT into XSL-FO generating XSLT. The end result of that was to simplify the maintenance of a website that published to both XHTML and PDF. Structure and style changes to the XHTML where propagated to the PDF output automatically... Sweet :)

More recently I have been looking at Schematron with a mind to using for unit testing. More on that will follow in due course.

Who knows what a node ID is?

The question of accessing a node in the source tree by it's identity depends upon which SVG viewer you are using.

Up until 9^th September 2005 you could rely upon two things:

1) If there was a DTD available, then your parser would identify id attributes as being of type ID if they were declared so in the DTD.

2) Your application assumed that when you use 'id' as an attribute name then it most probably was.

Either way you could use document.getElementById(id) to locate the uniquely identified node in the document tree.

Now with respect to SVG viewers, both Batik and ASV3 make an assumption about nodes in the source tree as being SVGElement nodes. As a result you can use document.getElementById(id) to locate metadata nodes that are not in the SVG namespace.

But, if they are not in the SVG namespace and not declared in the SVG DTD then they should not be accessible by this method. The two new implementations of SVG, Firefox 1.5 and Opera 9 have made this distinction. Neither of these browsers will allow you to use the DOM to retrieve nodes by their ID if they are not SVG elements.

However, there is light at the end of the tunnel. From 9^th September 2005 onwards there was a new W3C recommendation published that covered this exact problem. The xml:id recommendation identifies an new XML attribute, like xml:lang, that has a special meaning. If you use an xml:id attribute, the application processing your XML should interpret this as a unique identifier for the owner element regardless of the presence of a DTD or schema and I'm happy to say that Opera 9 supports xml:id but unfortunately, at this moment in time, Firefox 1.5 does not.

So, once again I find myself being bruised and bumped by web standards support.

SVG implementations and DOM support (Continued)

Now, what seems a fairly innocuous method turns out to be really rather important. The method I'm talking about is getComputedStyle().

Depending upon the client your running this could be a method of the window object (HTML browsers) or more officially it is a method of the document's defaultView. An example:

 initialValue = contextNode.ownerDocument.defaultView.
         getComputedStyle(contextNode, '').
                 getPropertyValue('visibility');

The above example gets the current value of the visibility style property of the context node. If you stop short and just get the computed style object, you will receive yards and yards of style properties that play a part in the styling of the context node. Which is great if, for example, you are creating a debugging tool like FireBug for the FireFox browser. Which I might add is seriously cool and if you don't have it then your missing-out.

Now there are a number of uses you can put getComputedStyle() to, one example is when creating a JavaScript implementation of the Synchronized Multimedia Integration Language (SMIL). You need it when setting-up the initial values of style properties you are about to animate.

There are some other ideas that I've had that could use this in relation to SVG. But , guess what?
The Adobe SVG Viewer 3 doesn't support getComputedStyle().

Grrrrrr!

SVG implementations and DOM support...

When it comes to web development you cannot get more 'Now' than working with Scalable Vector Graphics (SVG). You may think AJAX and the XMLHTTPRequest object is pretty cool but the Adobe SVG Viewer 3.0 (ASVG3) has supported a postURL method, that operates asynchronously, for years now, and for that matter so does the Apache open source SVG toolkit Batik.

But when you're pushing at the edges of things you start to notice where the cracks are. For example, If you pay attention to some of the tutorials/examples you will notice that you can use JavaScript to get the CSSStyleDeclaration object, for a node in your SVG DOM, by using the contextNode.getStyle() method. However, the W3C CSS DOM specification exposes this as a read-only property to be accessed thus; contextNode.style.

Now ASVG3 and Batik seem happy with either, but the FireFox 1.5 and Opera 9 browsers throw a thrum. So you'd better stick to the specs and use '.style' if you want to keep everyone happy.

You may be thinking why does this matter?

Well, unlike XHTML + CSS + DOM you cannot affect style changes just by using contextNode.setAttribute(propertyName, propertyValue). You have to get the context node's style object first and then use contextNode.setProperty(propertyName, propertyValue) instead. Bit of a mouthful? Well yes but it works, and maybe that's how it should work for all mark-up languages.

Exactly what it says on the tin...

I'm very much interested in being up-to-date. I take time to be up-to-date and I find it difficult to understand why people, especially in the IT business, could contemplate stagnation.

I own some wonderfully carved wooden bowls and pots made by Ian Chapman. Talking to him once at an arts and crafts fair I asked him why he had not made any more of the designs I liked and had previously bought. The way he works is this, he has an idea and he starts working on a piece of wood. He may create a number of pieces on that theme but as soon as he sees something different in the wood, a new direction, he follows that new path and NEVER goes back.

Edna Mode, from the truly wonderful film 'The Incredibles' made by Pixar summed this up when she declares to Mr Incredible,

"I never look back darling, it distracts from the now!"

That quote kind of sums up my approach to web development. I have many ideas, I knuckle down and pursue an idea until I see something more interesting and/or relevant, I'll then pursue that one in preference, but I never throw anything away!

After all, I learn and grow as I move along. But, there is one proviso, many threads that I have picked-up then dropped may be picked-up again at some point in the future and woven into new threads to take a new idea further. So it's not that I never look back, but I stand on all that I have made to enable me to reach higher.