Saxon diaries

Unicode, regular expressions, and Java

Michael Kay — Wed, 13 Jan 2010 17:00:12 +0000

Many moons ago, when I first introduced regular expression support to Saxon's XSLT processor, I picked up a piece of software written by James Clark to translate regular expressions as defined in the XML Schema specification to regular expressions as understood by Java. Like any software written by James, it was extremely robust, handled all the quirks of the underlying specifications with unfailing accuracy, was tightly coded and fast, and was totally undocumented.

One of the particular tasks it handled was to handle the fact that the Schema/XPath regex dialect counted characters above 65535 as one character, whereas the Java regex library until JDK 1.4 treated them as two.

Over the years I've modified the code a bit. When JDK 1.5 came along and handled high-end characters correctly, I forked the code and produced one version for JDK 1.4, another for JDK 1.5. A third version targetted the .NET regex dialect. In Saxon 9.2 I finally got rid of the JDK 1.4 version, and I was also able to get rid of the .NET version by switching from using the .NET regular expression library to the library in OpenJDK, which had finally become reliable enough.

Another of the tasks performed by James's code was to map character classes such as \P{Lu} (matching any upper-case character) from what XPath said it should mean to what Java thought it meant. This code has been untouched until now, but I've decided to take a fresh look at it and see whether it is really needed. Apart from the problem of high-end characters, it seems that what it was really doing was coping with differences between Unicode versions. It's a little hard to unearth the history now of which specifications mandated which Unicode version, but the current situation seems to be that JDK 1.5 and 1.6 support Unicode 4.0, while the schema (and hence XPath) specs originally specified Unicode 3.1, but now allow you to support whatever later Unicode version you like. So 4.0 support would be fine.

I've generated XML documents showing the mapping of characters to classes by three different methods: direct Java coding using the JDK regex engine; XSLT code using Saxon 9.2 which uses the Clark translation of regular expressions to the JDK engine; and analysis of the data files published by the Unicode consortium.

Between Saxon and the JDK there is a very close match. The only difference is that the JDK category C includes subcategory Cn (unassigned characters) whereas Saxon includes this subcategory in its parent class.

Between the data coming from Unicode and the JDK there is a less close match,. This was because I worked with Unicode 5.2 data files, which includes many more characters than the JDK understands. But I've repeated the comparison with Unicode 4.0.0 files, and this gives a very close match, after allowing for expected discrepancies such as the omission of surrogates (which are non-characters in XPath) in one of the lists.

So, it's looking as if I can cut out a lot more of James' translation code.

There does seem to be one snag that I need to look at further: in one of my attempts to collect this data, I used the complement classes such as \P{Cn}, replacing characters that matched this term with an empty string. The result was a string containing unmatched surrogates, which immediately crashes Saxon. This could be a bug in the JDK handling of surrogate pairs, or it could be something else that I don't yet understand. One of the difficulties with regex handling has always been that you're very exposed to bugs in the regex library for the final ounce of conformance, and if you hit them, there's sometimes not much you can do about them.

Importing a stylesheet module repeatedly

Michael Kay — Wed, 06 Jan 2010 08:07:03 +0000

I'm looking at a case submitted by a user where XSLT compilation is very slow. It turns out to be caused by the same module being repeatedly imported with many different import precedences (in the case of one module, with 174 different import precedences). The user has a solution (only import it once, or change some of the imports to includes); but I'm wondering what changes to make to prevent the problem recurring.

In this particular case, the stylesheet uses many functions and not many template rules. This is significant because the two cases are different: with functions, a named function that is masked by another with the same name and arity but higher precedence is dead wood: it can never be invoked, so all the costs of compiling it and optimising it are unnecessary. With template rules however, a template can always be reached using xsl:apply-imports or xsl:next-match, so it can never be discarded.

The specification says that including or importing the same module twice has exactly the same effect as if you included or imported two different modules that happened to have the same content. And that's exactly how Saxon behaves: it doesn't remember which modules have previously been read, so the second import/include causes the same document to be read from disk, parsed into a tree, and then to go through all the stages of XSLT and XPath static analysis. Clearly this involves a lot of wasted work.

The first question is, how much does this matter? How many users does it affect, and how badly does it affect them? It's impossible to answer the question statistically, so the usual test I apply is that if the code is correct and a reasonable user might write it in this way, then the software has a responsibility to try and execute it with reasonable efficiency. The principle (another one I remember from David Wheeler - he was an appalling lecturer, but he seems to have drilled some firm ideas into my brain) is "optimize the code that reasonable users actually write". And it does seem that a reasonable user, seeing that module A has a dependency on module B, might well add a redundant import declaration, and would not expect this to have an adverse effect on performance.

The next question is how far we should go in eliminating the unnecessary processing that is currently being done. Let's look at where the inefficiencies arise:

* We are parsing the same module repeatedly (about 10% of the cost), then parsing its XPath expressions repeatedly (another 10%), and doing other miscellaneous static checking (say another 5%).

* In the case of functions, we do a serial search to bind function calls to stylesheet functions, which is taking a long time because there are multiple instances of the same function. I have already implemented a hash lookup to fix this particular problem, which has halved the compilation time.

* Again in the case of functions, we are type-checking and optimizing functions that can never be called because they are masked by another of higher import precedence. This is another 10% or so of the overhead, and I have already made changes to eliminate it.

* In the case of template rules, the "masked" templates do need to be type-checked and optimized because they can be called, using apply-imports or next-match. However, we could potentially take advantage of the fact that two template rules with different import precedence can share the same executable code: if they come from different incarnations of the same module, then they will have identical static contexts, and could therefore be compiled once and share the same compiled code.

We can do some of these optimizations (like doing less work to process masked functions) without any change to the strategy of reading and parsing modules repeatedly. But other optimizations do mean that we need to recognize when two modules derive from the same source. In particular, we need to distinguish a "masked" function that comes from the same source module from a "masked" function deriving from a different source module: in the latter case, the spec requires all static errors to be detected even though the code is dead, while in the former case we know that we only need to do the analysis once to report all static errors.

The toughest aspect of this is that there is an impact on data structures. This is particularly the case with template rules: the idea of two template rules sharing the same executable code even though they have different import precedence, and then taking advantage of this to only type-check and optimize the code once. Changing data structures is always the hardest kind of change. But it's probably worth doing.

Pipedreaming: Could XPath have been better?

Michael Kay — Tue, 05 Jan 2010 11:30:06 +0000

I normally resist the kind of wishful thinking that tries to improve languages like XML or XPath without worrying about backwards compatibility. In practice you can never ignore the legacy: compatibility means deliberately repeating other people's mistakes, as David Wheeler used to say when I was an undergraduate. But it's New Year, so let's be absurdly optimistic, and assume that anything can be done. (And what set me on to this was actually something quite practical: Anthony Coates is looking at the XML support in Scala. Scala has a kind of XPath-like expression that adapts the XPath syntax into the Scala framework. So in such an environment, there is indeed an opportunity to rethink things.

Here are some of the changes I think I would make:

* Avoid the overloading of [] to act as both a filter and a subscript operator. Perhaps use [] for subscripting and ? for filtering, or perhaps use ! for subscripting and [] for filtering. The current overloading, especially because it is decided dynamically rather than statically, causes some very odd effects in edge cases. For the present, I'll avoid [] entirely, and use ? for the filter operator, and ! for subscript. We'll postpone decisions on operator precedence until later.

* Remove the special rules for subscripting when following a reverse axis. If X delivers items A, B, C, then X!1 delivers A, regardless of the nature of the expression X.

* The subscript operator would then be a simple binary operator: both operands would be evaluated in the same context. No special magic about N being a shorthand for position()=N. This removes the ability to use last() as a pseudo-subscript. Most languages seem to get by without such a feature, but I have to admit it is useful; I'd suggest either (a) a convention that negative subscripts number from the end (so X!-1 selects the last item), or (b) a separate operator, say ¡, to number backwards (it's high time we broke free from the shackles of ASCII...). Then X¡1 selects the last item in the sequence.

* Replace / with \ as the path operator, to avoid confusion with numeric division; and make it a pure mapping operator, with no implicit sorting into document order or deduplication. Remove all remaining restrictions on what can appear on the lh and rh sides. Use an explicit unary | operator for this purpose when required (so |EXP has the same meaning as ()|EXP, that is, take the nodes in EXP, deduplicate, and sort into document order).

* Lose the leading "/" in path expressions, as well as the lone "/" to refer to the root node. Instead use root() at the start of the path to get the root node of the tree containing the context node.

* Drop the abbreviation allowing E as a short-hand for child::E. Controversial, this one - the short-hand is very convenient. But it causes a lot of problems in making the grammar unambiguous and extensible. Replace it with a new abbreviation, on the same lines as "@" for the attribute axis: let's say ^. So a path expression might look like root()\^A\^B\@C. Not as pretty as what we are used to, but much more systematic, orthogonal, and extensible.

* This then suggests ^^ as an abbreviation for the descendant axis, replacing the current highly-illogical // pseudo-operator with its wierd syntactic expansion.

* Drop the implicit existential semantics for the "=" family of operators, giving them instead the same meaning that "eq" and friends have in XPath 2.0. Again, this removes a convenience in the interests of being more rigorous and orthogonal. It would be nice to offer something that's as general as the expression "some $x in X satisfies $x = 3" but less verbose; I would suggest prefixing any boolean operator or function name with "~" to indicate that it is to operate over sequences and behave existentially, so we have X ~= 3 to mean "some X equals 3", and ~contains(X, ('a', 'b')) to mean "some X contains 'a' or 'b'".

* Unify axes and functions. Conceptually, child::X applies the function child() to the context node and then filters the result with the predicate "is an X". There is no reason why "child" (the axis) should not be any function, rather than forcing it to be one of 13 magic functions built in to the system. There is also no reason why X (the nodetest) should not be generalised. Assuming a syntax .¿T to test whether the context node satisfies the nodetest T, X::T becomes a shorthand for X(.)?(.¿T), and this semantic definition paves the way to allowing X to be any single-argument function, and for generalizing nodetests to be any pattern. The overall effect is to make the semantics of XPath as a functional language much more explicit.

* Unify node tests and types. Both are essentially ways of classifying nodes (or other items). XPath 2.0 already goes some way towards making them interchangeable through the concept of "kind tests", but it could go further.

What is all this trying to achieve? The bottom line, I guess, is

(a) making the semantics of the language cleaner and more explicitly functional;

(b) removing quirkiness and non-orthogonality even where these quirks provide ways ways of expressing commonly used constructs more concisely

Of course, it's all an academic exercise. But perhaps it points the way to a better way of describing the current language by mapping the syntax onto a more regular core.

Patents: an Open Letter to my MP

Michael Kay — Mon, 14 Dec 2009 09:06:51 +0000

The Chancellor's recent pre-budget statement announces a measure (curiously named the "patent box") whose effect is to offer a reduced rate of corporation tax for profits deriving from patents. The stated intent is to encourage and reward innovation. As far as the software business is concerned, the effect is likely to be exactly the opposite...

Streaming templates - towards a more coherent design

Michael Kay — Thu, 10 Dec 2009 10:14:16 +0000

As previously reported, I've been making good progress in the last few weeks in implementing streaming templates: that is, the ability to write an XSLT stylesheet using template rules, in which the templates are activated in response to events notified by a SAX-style push parser, without ever building a tree in memory. However, there's something a little unsatisfactory about the state of play. Every time I write a new test case, there's a 50% chance I have to change the code to make it work. At this stage of the game, that's too high...

Intel joins the club

Michael Kay — Wed, 09 Dec 2009 00:30:21 +0000

I see from Twitter that Intel have now announced availability of a beta release of their XSLT 2.0 processor. Excellent news!

On the streamability of //section/head

Michael Kay — Tue, 01 Dec 2009 00:35:39 +0000

At first sight, nothing seems more eminently streamable than the expression <xsl:value-of select="//section/head"/>. The sections are in document order, the headings are in document order, the order of the output is the same as the order of the input, so where is the problem? The fact is, however, as I hinted in my previous post, there is a lot more to this expression than meets the eye.

On the streamability of //section/head

Michael Kay — Tue, 01 Dec 2009 00:34:43 +0000

At first sight, nothing seems more eminently streamable than the expression . The sections are in document order, the headings are in document order, the order of the output is the same as the order of the input, so where is the problem? The fact is, however, as I hinted in my previous post, there is a lot more to this expression than meets the eye.

Moving forward with streaming templates

Michael Kay — Thu, 26 Nov 2009 10:16:25 +0000

Saxon 9.2 introduced a limited capability to do "push processing" (using template rules) in streaming mode, that is, while parsing the source document, without ever building a tree representation of the source document in memory. This (added to the other streaming capabilities in Saxon) provides a useful capability for people who have to handle very large documents, but it only supports a small subset of the language, and achieving anything useful can sometimes require rather contorted programming. I've been revisiting the facility with the aim of supporting a much larger subset of the XSLT language in streaming mode, hopefully more like 80% rather than 20%, and thus making the streaming facilities far more accessible to the average developer. More...

A stylesheet conversion

Michael Kay — Thu, 20 Aug 2009 22:13:55 +0100

I'm doing what looks like a fairly simple project to upgrade an XSLT 1.0 stylesheet. It's XSLT 1.0 because it has to run in the browser, but fortunately it doesn't really need any 2.0 features. The old version of the stylesheet worked with XML files in format A, described by a DTD. The new version of the stylesheet has to produce the same HTML output, but this time from XML files in format B, described by an XSD schema...

Beyond Saxon 9.2

Michael Kay — Fri, 14 Aug 2009 20:16:10 +0100

So, Saxon 9.2 is finally out. I haven't had much chance to sit back and think yet - it's been a busy and stimulating week at the Balisage conference. Regulars will know that I don't do planning, either of dates or facilities: I prefer to keep the programme completely flexible, so that I can always find room to put new things in if the opportunity presents itself. But it's worth thinking a little bit about what's on the to-do list.

Analyzing dependencies in a class library: a use case for XSLT streaming

Michael Kay — Fri, 26 Jun 2009 18:01:10 +0100

IKVM (in version 0.40) now has much more complete coverage of the Java class library, but an unfortunate consequence of this is that the libraries have become rather large. To cut down the size of the library, we need to understand the dependencies between its parts. Read on to find how I'm doing this using the streaming facilities of the new Saxon 9.2 release...

Saxon repackaging

Michael Kay — Fri, 19 Jun 2009 22:44:31 +0100

Saxon9.2-EE is out on beta release, so the release process has finally started. It was beginning to feel as if the light at the end of the tunnel was an optical illusion. I decided not to change the licensing. GPL is just too distasteful, and other licenses that prevent use with commercial products just seem too burdensome. So here's what I've decided to do...

The GNU Public License

Michael Kay — Sun, 07 Jun 2009 17:47:55 +0100

I've been thinking carefully about whether there's a way to reduce the number of people "freeloading" on the back of Saxon - that is, selling commercial software that relies heavily on Saxon functionality without contributing anything in return. One potential way of doing that is switch in some way to a dual licensing approach: make application vendors choose between paying for a commercial license, and using the product under the GPL (GNU public license), which prevents them from creating "derivative works" unless those works are also licensed under the GPL (that is, made available as open source products). This is essentially the way MySQL works, and it seems to work well for them...

All nodes untyped

Michael Kay — Thu, 14 May 2009 09:34:08 +0100

Users sometimes imagine that just by running an application under Saxon-SA instead of Saxon-B, they will automatically get a performance boost. Sadly, this isn't the case. Sometimes Saxon-SA's more powerful optimizer will give a dramatic benefit, sometimes it will give none at all. In fact, sometimes if you move a workload to Saxon-SA without change, you see a performance regression. This is caused by the fact that Saxon-B can assume all nodes are untyped, whereas Saxon-SA can't make this assumption....

Repackaging Saxon

Michael Kay — Wed, 06 May 2009 13:32:31 +0100

I've been thinking for a while about some repackaging for Saxon, and I've now got to the point where I'm working out the fine detail and creating appropriate build files. The main idea is that instead of two products, Saxon-B and Saxon-SA, there will in future be three: Home Edition (HE), Professional Edition (PE), and Enterprise Edition (EE).

Streaming templates

Michael Kay — Mon, 23 Feb 2009 23:48:41 +0000

The streaming facilities in Saxon-SA have been proving very popular with those users who have very large documents to process. However, at present the only thing you can do in streaming mode is to split the document into a flat sequence of subtrees, and then process each subtree independently. That meets many needs, but not all. There are many simple tasks that can intrinsically be streamed despite the fact that they don't fit this model: for example, renaming all the elements in a document, or deleting all the NOTE elements. So I've started implementing "streaming templates", where the document is processed hierarchically in classic XSLT style by applying template rules to each node at every level....

Some threading tests

Michael Kay — Wed, 11 Feb 2009 18:20:43 +0000

Continuing the investigation of Tatu Saloranta's XSLTMark measurements, I was puzzled by the fact that on certiain tests, he was seeing a very different ratio between Saxon and XSLTC performance from the figures I was seeing.... I thought one theory worth testing was that XSLTC might be making better use of multiple processors than Saxon (which is essentially single-threaded).....

Another five-finger performance exercise

Michael Kay — Sat, 07 Feb 2009 13:16:52 +0000

Tatu Saloranta has started doing some work looking at the performance of XML parsers in an XSLT environment, and in that context he started running the old Datapower XSLTMark tests (no longer available, sadly) which are all 1.0 stylesheets, and the figures comparing Saxon and Xalan seemed to be worth investigating....

Bugs that don't crawl out of the woodwork

Michael Kay — Mon, 22 Dec 2008 15:30:05 +0000

I've said this before, but sometimes I'm truly amazed by some of the bugs I find: how on earth can they remain undetected for so long?

Ten Reasons why Saxon XQuery is Fast

Michael Kay — Sat, 13 Dec 2008 15:42:16 +0000

A paper under this title is published this month in a special issue of the IEEE Data Engineering Bulletin. Available online at:

http://sites.computer.org/debull/A08dec/saxonica.pdf

Of course, nearly all of what it says applies equally to XSLT. But for some reason, the academic community continues to be much more interested in XQuery.

Schema-Awareness and XMark performance

Michael Kay — Sun, 30 Nov 2008 21:27:41 +0000

When people ask what performance benefits they can expect from using schema-aware transformations and queries, I've often replied in a way that avoids setting expectations too high. Some queries can benefit significantly, others actually slow down because the extra cost of validating the input is not recovered by improvements in query execution speed. I've often stressed that the main benefit of schema-awareness is in the speed and ease of debugging and testing the query, not primarily in performance. But I've been taking another look at it, and I think I can probably start to be a bit more up-beat...

TEI Conference

Michael Kay — Tue, 11 Nov 2008 15:14:25 +0000

I spent a couple of days last week at the annual members meeting of the TEI (Text Encoding Initiative). It was good to meet so many Saxon users: a few familiar faces, rather more familiar names, and quite a few who introduced themselves as avid fans of the product, the book, or both...

XML Schema: allowing new lexical forms

Michael Kay — Thu, 23 Oct 2008 12:39:49 +0100

In a suggestion to the XML Schema Working Group, Axel Dahmen suggested defining a facet that allows the introduction of new lexical forms for existing data types. This would allow you, for example, to write a decimal value as "1,23", or a date as "12DEC2008", or a boolean as "yes". The Schema WG has already put out two "last call" drafts of the XSD 1.1 spec, so it's not really welcoming ideas for new features at the moment, but I thought I would take a look at this one independently...

Software Patents

Michael Kay — Thu, 02 Oct 2008 12:20:25 +0100

I have absolutely no doubt that software patents are unquestionably a bad thing. It simply isn't in the public interest to grant them. The only possible reason for doing so is to reward and encourage innovation, and there is no evidence that they have that effect, and plenty of evidence that they do exactly the opposite...

Just-in-Time Optimization

Michael Kay — Sat, 20 Sep 2008 21:44:53 +0100

Rereading my last post on compile-time performance, the thought leaps out at me: if I don't want to rely on users setting a switch to control whether optimization happens or not, then I should be doing lazy (or just-in-time) optimization...

More thoughts on compile-time performance

Michael Kay — Thu, 18 Sep 2008 19:11:59 +0100

Another user has sent me some samples of generated code (XSLT this time) with a request to take a look at compile-time performance issues. It takes about 3900ms to compile (5000ms under Saxon-SA), and the new switch to suppress optimization reduces this to about 1180ms. So optimization is the culprit here. So the switch will be useful here. But I hate performance improvements that depend on the user setting a switch, because 99% of users will never discover the switch is there. So, are there opportunities to improve the compile-time performance of the optimizer? You bet there are....

Compile-time Performance

Michael Kay — Tue, 16 Sep 2008 12:48:43 +0100

There was a support request a couple of days ago asking for a switch to turn optimization off. The user had a large query that was taking a long time to compile, and naturally felt that the cost could be reduced by omitting the optimization phase. But as always with performance, assumptions are dangerous until they have been verified by measurement...

Tweaking the TinyTree

Michael Kay — Wed, 10 Sep 2008 08:26:44 +0100

It's unusual to find anything these days that gives Saxon a 5% performance boost across the board, but I seem to have achieved that with some tweaks to the TinyTree data structure...

There's an R in the month

Michael Kay — Mon, 01 Sep 2008 10:57:15 +0100

September is upon us; summer is over; so it's time to start thinking about a new season. This blog has become rather dormant. Well, I'm going to try and reform, and post more regularly, and if I haven't got much to say then I'll just witter on about what I've been up to recently...