Supporting XSLT 2.0 (Was: Comments from the XSLT WG on the XProc Last Call Document)

Speaking for myself once more...

Sharon Adler wrote:
> From: XSLT WG
> 5. We think it's wrong that support for XSLT 1.0 should be mandatory and
> XSLT 2.0 optional. We would suggest that XProc processors be required to
> support at least one XSLT version without specifying which one. As currently
> specified, XProc is storing up a problem for itself in the future when XSLT
> 1.0 starts to fade into obsolescence.

I'd hope that by the time XSLT 1.0 is obsolescent, XProc 1.0 will be 
too, but I don't have any vehement objections to allowing 
implementations to choose which version to support. After all, even if 
they only support XSLT 2.0 they're likely, for the forseeable future, to 
support the backwards compatibility feature which means that they'll do 
XSLT 1.0 processing if presented with an XSLT 1.0 stylesheet.

> 6. Having two separate tasks (step types?) for XSLT 1.0 and XSLT 2.0
> suggests a poorly thought-out strategy for versioning. Version control
> surely affects processors other than XSLT? A more general mechanism might be
> to have standard attributes of a task/step that determine the version of the
> specification and/or implementation required for execution of this step
> (allowing users to take the default if they don't care).

The main problem with XSLT 1.0 vs XSLT 2.0, for us, was that they have 
different signatures. We did look at using a single step type for both, 
but there were so many extra options (and indeed an extra output port) 
for the XSLT 2.0 version that they looked like different processes.

But I agree that it would be good to have a better versioning story.

What about this as a suggestion:

Step types are defined by a combination of their name and their version 
(a decimal, or possibly a token to allow things like "1.0+exslt"). It's 
possible to have multiple step types with the same name available within 
a pipeline, as long as they have different versions. Different versions 
of the same step type can have different signatures (different input and 
output ports and different options).

The p:step-available() function would take an optional second argument 
that would indicate the version of the step type being tested for. For 
example, if I did p:step-available('my:preprocess', 1.1) it would return 
true if the my:preprocess step was available in version 1.1, whereas 
p:step-available('my:preprocess') would be true if any version of 
my:preprocess was available.

When users invoke a step, they could provide a version attribute on the 
step invocation, to indicate which version of the step type they want to 
use. It would be a static error if the signature of the invocation 
doesn't match the signature of that version of the step type.

Then the question is what to do if the version attribute hasn't been 
specified by the user. Options include:

A. Make the version that gets used implementation-defined. It would be a 
static error if the signature of the invocation didn't match the 
signature of the version of that step type that the implementation has 
chosen. For example, if someone wrote a pipeline that worked with an 
XProc implementation that supported p:xslt version 2.0 by default, and 
then tried to run it on an XProc implementation that supported p:xslt 
version 1.0 by default, then they might get a static error (if, for 
example, they tried to hook into the 'secondary' output port or specify 
a template-name option).

B. Define which version got used using a rule like: the implementation 
must use a version of the step type that matches the signature used in 
the invocation of the step; if it supports two versions whose signature 
matches, then it must use the one with the greater version number 
(assuming that the versions are decimals). If it doesn't support any 
version whose signature matches that of the invocation then it must give 
a static error. This would prevent the error described above if the 
second XProc implementation supported both XSLT 1.0 and XSLT 2.0 (but 
not if it only supported XSLT 1.0).

C. (Simpler, especially for tools like editors that don't know what the 
capabilities are of the implementation you'll be using), if the version 
is missing, it defaults to 1.0; if users want to use a different 
version, they have to specify it explicitly.

I think C. will give the greatest portability, but it might feel like 
the wrong default for certain processes (such as XSLT) in the future.

Cheers,

Jeni
-- 
Jeni Tennison
http://www.jenitennison.com

Received on Friday, 26 October 2007 20:06:25 UTC