Re: result documents in an XSLT step?

The spec tries to explain the difference between step-evaluated and 
processor evaluated expressions: 
https://spec.xproc.org/master/head/xproc/#xpath-context

David’s observation about the difference between p:filter/@select and 
p:with-input/@select is a consequence of this distinction: 
p:with-input/@select is evaluated by the processor, p:filter/@select is 
evaluated by the step.

A step that evaluates these expressions sees the input documents, so it 
can select descendant::item, but when evaluating the expression, it does 
not see the pipeline’s variable bindings, such as $current-paradigm. 
Therefore it cannot select descendant::item[paradigm eq 
$current-paradigm]. As David noticed, a workaround is to use AVTs which 
makes these step-evaluated expressions less unwieldy than in XProc 1.0 
where I needed to write something like this:

<p:add-attribute attribute-name="extract" attribute-value="true">
   <p:with-option name="match"
     select="concat(
               'c:file[matches(@name, ''', $name-regex, ''')]'
             )"/>
</p:add-attribute>

One reason why p:filter cannot access variables from the environment in 
expressions is that the processor-implemented atomic steps shouldn’t be 
privileged over extension steps that are implemented by some other 
software. Any atomic step can only access variables from the environment 
in p:with-option/@select or as an attribute value template in the case 
of syntactic shortcuts.

So while you can say that an option string should be interpreted as an 
XPath expression, you cannot declare an option of your step an XPath 
expression that is evaluated with the processors in-scope variable 
bindings. Think of a step my:squared that accepts an integer value and 
returns the squared value (wrapped in an element, probably).

<p:variable name="number" select="2" as="xs:integer"/>

<my:squared select="$number"/>

is equivalent with

<my:squared>
   <p:with-option name="select" select="'$number'"/>
</my:squared>

How do you declare this step?

<p:declare-step type="my:squared">
   <p:option name="select" as="xs:string"/>

And then you probably have access to a function that evaluates $select 
as an XPath expression, maybe by importing an XSLT function that 
interfaces the xsl:evaluate instruction.

But at this point I hope it becomes clear that xsl:evaluate knows no 
binding for the expression $number that it encounters in the XPath string.

It is an interesting detail that for p:viewport/@match, the XProc 1.0 
versions of Calabash and Morgana took a different approach with respect 
to making variable bindings available in the @match XPath expression. 
Morgana knew about the outside variables, Calabash didn’t. This drove me 
nuts: 
https://github.com/xproc/3.0-specification/issues/830#issuecomment-509133805

Achim and I convinced Norm that Calabash should know the bindings in 
p:viewport/@match expressiona, and that p:viewport/@match shouldn’t 
become an AVT where you need the curly braces but ultimately form a 
string value that is evaluated without knowing the bindings.

This is acceptable because p:viewport is a processor-evaluated step, and 
the processor may well use its knowledge of in-scope bindings when 
evaluating XPath expressions given in attributes.

Gerrit



On 02.11.2020 19:56, Martin Honnen wrote:
> On 02.11.2020 18:41, David Birnbaum wrote:
> 
>> For future reference, though, I'd be grateful for the opportunity to
>> confirm the source of my misunderstanding of how to use <p:filter> — not
>> only my failure to use a wrapper (I understand why that's important),
>> but why it requires curly braces inside single quotation marks inside
>> the double quotation marks around the value of the @select attribute. By
>> way of attempting my own explanation: The spec at
>> https://spec.xproc.org/master/head/steps/#c.filter says that @select on
>> <p:filter> is a string, and that "the select expression is computed
>> dynamically." Meanwhile, the other spec at
>> https://spec.xproc.org/master/head/xproc/#p.with-input says that @select
>> on <p:with-input> is an XPath expression. I think my mistake was
>> assuming (instead of checking the spec carefully) that the value
>> of @select would always and everywhere be an XPath expression, as (I
>> think) it is inside XSLT wherever it is part of the signature of an
>> element in the XSLT namespace. If it is a string, though, I need to
>> dereference the string value of $current-paradigm, put it in quotes, and
>> use that as one of the comparands inside the predicate, and the literal
>> single quotes become the quotes around the string value and the curly
>> braces inside them serve the usual AVT function of interpreting the
>> XPath expression in place.
> 
> I will leave the explanation to the XProc guys but as for your
> description and the difficulties to understand the difference, I think,
> if you don't already have it, consider to get Erik Siegel's book on
> XProc 3 (XProc 3.0 Programmer Reference), he has a section explaining
> when XPath expressions are evaluated by the pipeline and when they are
> evaluated by the step itself.
> 
> In general I think his book is very helpful to serve as an introduction
> to a user of XProc 3, better than the specs which by their nature are
> too formal and more geared towards implementors.
> 
> 
>

Received on Monday, 2 November 2020 20:57:45 UTC