xsl-list
[Top] [All Lists]

Re: [xsl] Can an XSLT 3.0 stylesheet access the complete sequence of values passed in as the initial match selection?

2020-01-14 04:24:57


On 14.01.2020 10:25, Martin Honnen martin(_dot_)honnen(_at_)gmx(_dot_)de wrote:
Am 13.01.2020 um 13:27 schrieb Imsieke, Gerrit, le-tex
gerrit(_dot_)imsieke(_at_)le-tex(_dot_)de:
As you observed, with XProc 3.0, when using p:xslt in XSLT-3.0 mode, a
transformation that is invoked without an initial template is supposed
to process each document of the input sequence individually. The
default collection is undefined.

There was no /compelling/ reason to deviate from XProc 1.0 behavior,
only these:

– It is more in line with the apply-templates invocation as specified
by XSLT 3.0.

– Norm in particular doesn’t like first-value semantics

We thought that migrating their existing stylesheets isn’t too
demanding for pipeline authors:

– They can simply invoke the transformation in XSLT-2 mode and get to
keep the old behavior.

– If they were already using a named template they don’t need to
change a thing about the default collection even when they now use
XSLT-3 mode.



So the way the source port is used and whether or not the default
collection is bound to the documents on the source port depends on that
you call the XSLT-mode? Is that the version specified in the version
attribute of the p:xslt step?

Yes, the version attribute is the premier way to enforce a certain behavior. Without it, the XProc processor will determine a version for you. Most likely it will look at the top-level stylesheet’s version attribute.


How will that work in a setup with a current version (e.g. Saxon 9.8 or
9.9) of Saxon as the XSLT processor. It supports XSLT 3 but no longer
XSLT 2. The spec says "If the step specifies a version, then that
version of XSLT must be used to process the transformation. It is a
dynamic error (err:XC0038) if the specified xslt version is not available".

If the XProc processor uses Saxon 9.8+, it has the liberty to bail out if XSLT 2 is explicitly requested, claiming that the XSLT processor at hand does not support XSLT 2. This would be a stupid thing to do though because, as is stated in the Saxon documentation:

“XSLT 3.0 has a very high level of backwards compatibility with XSLT 2.0, so all existing stylesheets should continue to run. The only significant difference when you process a 2.0 stylesheet with a 3.0 processor is that you will no longer get errors if you use constructs that are permitted in 3.0 but not in 2.0.”

So the XProc processor will probably declare that it will use Saxon for XSLT 2 processing, with the specified bahavior for XSLT 2 operation: All source port documents go into the default collection all of the time; process only the first document in sequence in the absence of the template-name option. It will refer to the Saxonica documentation with respect to the few possible restrictions when running an XSLT 2 stylesheet with Saxon 9.8+.


Is the XProc processor then supposed to use Saxon 9.8 or 9.9, an XSLT 3
processor, to run with the settings in
https://spec.xproc.org/master/head/steps/#c.xslt.11 for invoking XSLT 2?

Yes. Keep in mind though that the XProc processor is not required to use any version of Saxon at all. In practice, the next version of XML Calabash will be closely intertwined with Saxon 9.9 while I think Morgana XProc III will still offer Saxon support as an add-on (with no other viable options for a readily available XSLT 2 or 3 processor AFAIK).


I guess this is possible but I previously understood "then that version
of XSLT must be used" rather like "an XSLT 2 processor" is available and
has to be used.

I’d expect that an XProc processor that bundles Saxon 9.9 might get away with stating that it does indeed provide XSLT 2 support: By using the XSLT 3 processor with the specific provisions of https://spec.xproc.org/master/head/steps/#c.xslt.11

But I will raise an issue that we will discuss in the next editorial meeting (Jan 23).

Others might be inclined to say that an XProc processor that bundles Saxon 9.9 may not claim that it provides XSLT 2 support at all. If this is the standpoint, an XProc processor may still offer a configuration option to bypass this rather pedantic check.

Gerrit
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--

<Prev in Thread] Current Thread [Next in Thread>