Am 13.01.2020 um 13:27 schrieb Imsieke, Gerrit, le-tex
gerrit(_dot_)imsieke(_at_)le-tex(_dot_)de:
On 12.01.2020 22:21, Martin Honnen martin(_dot_)honnen(_at_)gmx(_dot_)de wrote:
On 12.01.2020 20:44, Michael Kay mike(_at_)saxonica(_dot_)com wrote:
You can only process the items individually; which I'm afraid makes the
feature rather useless.
The XProc 3 guys seem to want to use it:
https://spec.xproc.org/master/head/steps/#c.xslt.10 says: "If no value
is supplied for template-name option an “Apply-template invocation” is
performed. The documents that appear on source are taken to be the
initial match selection.".
In XProc 1.0, when there is no initial named template specified, the
first document on the source port is processed and all source port
documents go into the default collection. We often use this, although
a downside to it is that these stylesheets don’t lend themselves to
standalone invocation. Passing documents or other structures as
parameters isn’t possible with XProc 1.0, therefore having access to
the input all at once per default collection is quite useful. In order
to make XSLT code portable for standalone invocation, one would
typically write two small frontend stylesheets that import the core
functionality, one for XProc invocation and one for standalone.
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?
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".
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?
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.
--~----------------------------------------------------------------
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
--~--