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

["Martin Honnen martin.honnen@xxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

Am 13.01.2020 um 13:27 schrieb Imsieke, Gerrit, le-tex
gerrit.imsieke@xxxxxxxxx:
> On 12.01.2020 22:21, Martin Honnen martin.honnen@xxxxxx wrote:
> > On 12.01.2020 20:44, Michael Kay mike@xxxxxxxxxxxx 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 bApply-template invocationb 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 donbt lend themselves to
> standalone invocation. Passing documents or other structures as
> parameters isnbt 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:
>
> b It is more in line with the apply-templates invocation as specified
> by XSLT 3.0.
>
> b Norm in particular doesnbt like first-value semantics
>
> We thought that migrating their existing stylesheets isnbt too
> demanding for pipeline authors:
>
> b They can simply invoke the transformation in XSLT-2 mode and get to
> keep the old behavior.
>
> b If they were already using a named template they donbt 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.