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
--~--