Notes on the Interoperability Workshop

Notes on XSLT 3.0 Interoperability Workshop held at XML Prague Feb 13th 2016

Workshop led by Michael Kay and Abel Braaksma

The workshop was given a 3-hour slot at the conference, and was well attended (perhaps 100 people present); there was a good level of interest from the audience and they seemed well-informed.

We stated the objectives as being:

Interoperability testing (demonstrating that we met the W3C requirement for interoperable implementations of the specification to exist)
Tutorial – introduce people to the features of the spec and give a chance to ask questions
Usability testing – establish whether the language was suitable for its intended purpose and capable of being used by its intended audience.

We had prepared material in advance at a github repository (Saxonica/Prague2016) and invited people to download this and try it (or their own variations) on their own, and provided access to two implementations (Exselt and Saxon-EE 9.7).

Generally our modus operandi was that one of us would demonstrate stylesheets running against one product, and the other (using a second projector) would mirror the same stylesheets running against the other product, so that the audience could see the results of both products side by side and compare. There was a mixture of prepared material and material entered interactively on the day, but none of it had previously been exposed to both products.

Our aim was to cover three areas: "minor goodies", streaming, and packaging. In the event we spent 90 minutes on minor goodies (which attracted a lot of questions and interaction), 60 minutes on streaming, and 30 minutes on packaging.

My conference talk on the previous day had focused on JSON support in XSLT 3.0 (including maps and arrays) so we decided to give that less emphasis in the workshop.

Abel started by presenting features such as text value templates and static parameters, illustrated with many small examples, most of which ran successfully in both products. The exception was a test using the item-separator output parameter, which hit a documented limitation in Saxon 9.7.

I introduced the session on streaming with a MusicXML example. I presented a version of a stylesheet to extract selected parts from a musical score, which worked successfully on both products. This was a moderately complex stylesheet using a range of features (accumulators, maps, streamable templates). Audience response suggested a good level of understanding of how the stylesheet worked and why it had to be written the way it was. With input from the audience we tried a number of variations (other ways of achieving the same effect, or slightly different effects). This exercise found deficiencies in both products (for example a crash rather than proper diagnostics when faced with non-streamable code, or reporting code as non-streamable when it was guaranteed streamable according to the spec) This has resulted in test cases being added to the test suite.

In the last half hour we presented the CSV example stylesheet from the spec and the test suite as an example of packages and overloading of components. This ran successfully on Exselt but failed on Saxon; it turned out that this was due to a known bug which had been fixed in the current maintenance release, but we were using a version in which the bug was not fixed (Saxon incorrectly reports a circular dependency between packages when run from the command line). (The example was already in the test suite, so it was known Saxon should run it, but the bug was in the method of invocation). Feedback indicated some puzzlement over the question of how to make implementations aware of where packages can be located; the spec leaves this question entirely implementation-defined.

There were no success criteria as such, but I stated at the beginning that if we did not find any issues then we would have failed, and in this we were not disappointed. We deliberately chose not to be over-cautious in what we attempted, and I think the result was that the audience was left with a very honest picture about the level of maturity of the implementations of the standard: approaching completeness, but still with some polishing to do in the final stages.

Michael Kay