Re: XSLT version

Norman Walsh wrote:
> Suppose instead we say that there's a single, required p:xslt step and
> an implementation may implement XSLT 1.0 or XSLT 2.0 (or both) at its
> option.
> 
> Here's the proposed signature:
> 
> <p:declare-step type="p:xslt">
>      <p:input port="source" sequence="true" primary="true"/>
>      <p:input port="stylesheet"/>
>      <p:input port="parameters" kind="parameter" sequence="true"/>
>      <p:output port="result" primary="true"/>
>      <p:output port="secondary" sequence="true"/>
>      <p:option name="initial-mode"/>
>      <p:option name="template-name"/>
>      <p:option name="output-base-uri"/>
>      <p:option name="version"/>
> </p:declare-step>

What's the 'version' option do?

> If the pipeline author requests a version of XSLT that the
> implementation does not support, the implementation SHOULD report a
> dynamic error. If the pipeline author doesn't request a version, the
> implementation may run any version it wishes, and may use any criteria
> it wants, including sniffing the XSLT stylesheet to make that
> determination.
> 
> If XSLT 1.0 is run, it is a dynamic error unless exactly one document
> appears on the source port. The secondary result port will always
> return an empty sequence.
> 
> It is implementation-defined if the initial-mode, template-name, and
> output-base-uri options are supported for the version of XSLT that is
> used.
> 
> The allow-version-mismatch option is removed; you get what the
> implementation gives you.
> 
> The allow-collections option is removed; if you run XSLT 2, the
> sequence of documents that appears on the source port is always the
> default collection.

That works for me. XSLT's forwards- and backwards-compatibility mean 
that the version specified in the stylesheet will determine how it's 
interpreted.

Cheers,

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

Received on Friday, 9 November 2007 20:45:35 UTC