- From: Jeni Tennison <jeni@jenitennison.com>
- Date: Fri, 26 Oct 2007 21:06:12 +0100
- To: public-xml-processing-model-comments@w3.org
- CC: W3c-xsl-wg@w3.org
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