Re: result documents in an XSLT step?

Dear Gerrit (cc xproc-dev),

Thank you for the detailed and very helpful explanation, which clarifies
how and why XProc distinguishes evaluation by the step and evaluation by
the processor. I had not recognized initially the importance of this
distinction, and the consequences it implies.

Best,

David

On Mon, Nov 2, 2020 at 3:58 PM Imsieke, Gerrit, le-tex <
gerrit.imsieke@le-tex.de> wrote:

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