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.
b Alternatively, they need to change the thin veneer of a frontend
stylesheet by introducing a named template instead of processing the
first document. Of course stylesheets that refer to both / and to
collection() all the time might need a more thorough rebrush if they
were to be invoked in XSLT-3 mode: Something like <xsl:variable
name="root" as="document-node(element(foo))"
select="collection()[foo]"/>, and replace / with $root/.
As with any other decision taken in XSLT 3.0, we didnbt question the
usefulness of the specified behavior. We often try to align behavior
with XSLT 3.0 if the premises are similar and if there are no good
reasons to do otherwise.
One minor side effect of the new behavior is that one can save a
p:for-each loop when a sequence of documents should be transformed.
Allowing pipeline authors to write more concise pipelines was one of the
design goals for XProc 3.0. However, this benefit is only marginal. If
you need to validate each result document, you end up with a loop again.
Or youbd encapsulate all your sequence processing, transformation, and
validation in a single, user-defined step anyway.
It seems there you can pass in more than one item (document in the XProc
terminology) on the source port.
Any XProc 3 expert out there that knows whether a stylesheet in an xslt
3 step will need a step doing a wrap or merge/join before the xslt step
to be able to have the xslt step process the whole source port selection
of items together in the XSLT code?
I think the default collection / named template invocation covers this.
Gerrit