Why choice in software matters … a story from the real world

Ten years ago today something happened that has had a significant impact on many millions of people across the world … Mozilla 1.0 was released.

Image via CrunchBase

Above all else Mozilla, and it’s leaner, fitter, offspring, Mozilla Firefox, is the most important piece of free (as in freedom) software ever produced. For sure, it stood on the shoulders of giants to get there, but by giving the world a real choice in browsers the Mozilla Foundation changed the rules for the Internet, forced Microsoft to get its act together and crushed that company’s attempts to bind us all into a proprietary software future (remember ActiveX anyone?) online.

It is probably going too far to say that without Mozilla there would be no Arab Spring, for instance, but maybe not by much. Because Mozilla and Firefox also taught the public that there were alternatives out there and so the future did not have to be about what ever Baby Blue said it was. And that willingness to experiment online is helping power the mass adoption of smart phones, which are the weapons of choice for online revolutionaries.

It is easy to forget how bad it had got before Mozilla came along … Internet Explorer was a truly atrocious application that was not updated for several years. Microsoft had no interest in open standards because it had no competition. Mozilla changed all that. Not instantly, but the pressure began immediately.

Related articles

• Mozilla loses Web technology guru Chris Blizzard (news.cnet.com)
• Crazy Geckos: Nitot on Mozilla’s post-Firefox mobile crusade (go.theregister.com)
• Windows RT will ban Firefox and Chrome, says Mozilla (csmonitor.com)
• A history of Mozilla browsers design (nicubunu.blogspot.com)
• Mozilla grudgingly adopts H.264 (theinquirer.net)

Using XSLT to manipulate an SVG file

I am generating a lot of the graphics for my project using Scalable Vector Graphics (SVG) – an XML format.

The advantages of SVG are obvious – it is human readable, it preserves some of the data in the output (eg in the relative placing of the dots on a graph), Groovy has good support for it and, in theory at least XML Stylesheet Transformations (XSLT) means that it can be manipulated outside of a formal programming environment using another bit of XML (an XSL stylesheet) and freely available XSLT tools – eg xsltproc on Linux.

But XSLT is one of those Cinderellas of the computing world – widely relied on but not generally understood or widely discussed. As a result I have struggled over the last 24 hours to work out how to do what ought to be a simple thing: removing a set of dots of one colour from an SVG. I still have not got to the bottom of all the issues – specifically xltproc seems to have an issue with XML namespace declarations and/or DTD declarations – but I have fixed it for all practical purposes, so thought I should document it for future users…

Before I describe the problem more fully as well as the solution, I have to recommend this book – XSLT: Mastering XML Transformations. For Beginners and Advanced Users – which gave me the pointers to a solution I just could not find online.

So here is the graph (in PNG format because WordPress does not support SVG) I want to manipulate.

This is memory map – via Valgrind – of Firefox (7) opening and closing (I created a page that, once Firefox was configured, would close the browser.)

The different types of memory accesses – for instructions (red), loads (blue), stores (yellow) and modifies (green) are all on superimposed and which colour you see depends on the order they are written if they access the same page.

So the answer, with an SVG, is obvious, just look at the colour you want to see.

Ought to be easy, right? Well, I suppose when you know how to do it, it is easy. But it’s not completely simple!

Each dot on the graph is drawn with an XML element like this:

<circle cx='102' cy='699' r='1' fill='none' stroke='red' stroke-width='1' />

The trick is to create a template for all the elements but inside that template only copy out the elements that match the correct stroke attribute. (Attributes are not children of node elements either, so you have to copy them out explicitly.)

Here’s a stylesheet that does it:

<?xml version="1.0"?>
<xsl:stylesheet version="1.0" indent="yes"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:param name="colour">yellow</xsl:param>
<xsl:template match="/">
	<xsl:apply-templates select="svg"/>
</xsl:template>
<xsl:template match="svg">
	<xsl:copy>
		<xsl:for-each select="@*">
			<xsl:copy/>
		</xsl:for-each>
		<xsl:text>
</xsl:text>
		<xsl:apply-templates select="rect"/>
		<xsl:apply-templates select="line"/>
		<xsl:apply-templates select="text"/>
		<xsl:apply-templates select="circle"/>
	</xsl:copy>
</xsl:template>
<xsl:template match="line">
	<xsl:copy>
		<xsl:for-each select="@*">
			<xsl:copy/>
		</xsl:for-each>
	</xsl:copy>
<xsl:text>
</xsl:text>
</xsl:template>
<xsl:template match="rect">
	<xsl:copy>
		<xsl:for-each select="@*">
			<xsl:copy/>
		</xsl:for-each>
	</xsl:copy>
<xsl:text>
</xsl:text>
</xsl:template>
<xsl:template match="text">
	<xsl:copy>
		<xsl:for-each select="@*|node()">
			<xsl:copy/>
		</xsl:for-each>
	</xsl:copy>
<xsl:text>
</xsl:text>
</xsl:template>
<xsl:template match="circle">
	<xsl:if test="@stroke=$colour">
		<xsl:copy>
			<xsl:for-each select="@*">
				<xsl:copy/>
			</xsl:for-each>
		</xsl:copy>
		<xsl:text>
</xsl:text>
	</xsl:if>
</xsl:template>
</xsl:stylesheet>

(This code be shortened to just copy-of the line, rect and text elements.)

And here’s an example:

xsltproc  -o inst.svg --stringparam colour "red" pickcolour.xsl master.svg

Time to ditch Firefox?

Image via Wikipedia

Just about every internet user, even if they have never used Firefox, owes the Mozilla Foundation an enormous amount for the creation of Firefox.

It’s injection of competition back into the mass browser market stimulated a new drive towards standards and speed that has made a huge difference to all users: Internet Explorer 6 came out in 2001 and languished, largely unimproved until Firefox’s success finally prompted a new version of IE, in 2006 and since then competition has been fierce.

But is Firefox really up to it any more? I have just tried the javascript bench marks on http://jsbenchmark.celtickane.com and my copy of Firefox (it is still my browser of choice at home) scored just 89 on average over 10 runs. Google Chrome managed 313 on the same box (a now quite old Pentium D).

And, of course, Chrome is more standards compliant. It doesn’t quite smoothly progress to 100/100 on the Acid 3 test – but it does get there, while my version of Firefox only manages 94/100.

530 lines of Javascript

I have just written that amount of code in what I persist in thinking of as a toy language (it was actually somewhat longer until I refactored the code to group some common functions together),

I had to do this for a coursework exercise – a lot of effort to be honest for what is at stake – processing a rather large XML file with some XSL. The Javascript essentially manages the parameters.

At the end my conclusion is that I don’t really see why anybody would want to write that much client code if they could possibly help it. Of course it transfers the computational burden to the client – but at the cost of hundreds of lines of interpreted code which is essentially under the control of the people who write the engines in the Firefox and IE browsers. In the real world that points towards a support nightmare.

Having written a fair bit of Perl (and AJAX) stuff in the past the whole thing felt unnatural – dozens of lines, much of it designed to handle the differences between the browser engines, that could have been handled simply on the server side.

One thing that I was convinced of was the potential power of XSLT: though I was not quite prepared for the revelation that it is Turing complete (ie it would be possible to write some XSL that would process any algorithm/task solvable through a finite number of mechanical steps). Though I shudder to think of how big a stylesheet would be required to handle all but the smallest of task.

But the potential power of XSLT is not the same of thinking of many practical uses for it!

Dealing with 0x80600001 errors

Maybe you have just seen a message like this:

Error: uncaught exception: [Exception… “Component returned failure code: 0x80600001 [nsIXSLTProcessor.importStylesheet]”  nsresult: “0x80600001 (<unknown>)”  location: “JS frame :: file:///home/adrian/webtech/cia.html :: fulltable :: line 47”  data: no]

If you have then chances are you are working on some XSL/XSLT (the above comes from a piece of coursework I am working on which manipulates an XML representation of data from the CIA World Fact Book).

The error indicates that your XSL is broken and non-compliant and the problem is that Firefox/Mozilla is much stricter about what is broken than it is likely your command line XSLT processor is: the piece of XSL which generated the above message seemed to fly through xsltproc on my Linux box.

The best way to fix this is to take out the lines, one by one, from your XSL and look for the one that breaks the transformation. To avoid being inadvertently tied up in some issue of plagiarism later on I cannot post the XSL I was working on when this came up, but I had a line like this:

<xsl:apply-templates match="//item"/>

That is bad XSL – the match should be a select but as xsltproc happily covered up for my mistake and generated the XHTML I was looking for I could not understand why Firefox was flagging the error on this line of Javascript xsltproc.importStylesheet(xmlxsl).

It also took me a while to find an online explanation, so I wrote this.