W3C home > Mailing lists > Public > xproc-dev@w3.org > November 2020

Re: result documents in an XSLT step?

From: David Birnbaum <djbpitt@gmail.com>
Date: Mon, 2 Nov 2020 12:41:36 -0500
Message-ID: <CAP4v81pEcTxOuY5gk1PFR_mzrtff_VxaAgyOTEmi7F_c5SK+dA@mail.gmail.com>
To: Martin Honnen <martin.honnen@gmx.de>
Cc: XProc Dev <xproc-dev@w3.org>
Dear Martin (cc xproc-dev),

Thank you for your two messages, one about using <p:wrap-sequence> with
<p:with-input> and the other about using <p:filter>. I've implemented the
first, and I understand how it works, and why it is superior to (simpler
and clearer than) the <p:filter> approach.

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.

If the preceding is incorrect, I would be grateful for a pointer in the
right direction. I wonder whether someone (perhaps someone on the XProc dev
team?) might be able to explain why it was decided that @select should
behave differently on <p:with-input> and <p:filter>. I don't mean to
suggest that this was the wrong decision, since 1) I am confident that it
was made for good reason and 2) it is the reality, whatever the reason, but
understanding what motivated the decision to implement different behaviors
might help me both remember the difference in this case and figure out
similar questions in the future on my own.



On Sun, Nov 1, 2020 at 11:24 AM Martin Honnen <martin.honnen@gmx.de> wrote:

> On 01.11.2020 16:13, David Birnbaum wrote:
> > <p:filter name="filtering" select="descendant::item[paradigm eq
> > $current-paradigm]">
> For p:filter I think you would need
>    <p:filter name="filtering" select="descendant::item[paradigm =
> '{$current-paradigm}']">
> but it would still need a wrap-sequence to not return a sequence of
> different documents where each has an "item" but instead return a single
> document wrapping all selected item elements.
Received on Monday, 2 November 2020 17:41:59 UTC

This archive was generated by hypermail 2.4.0 : Monday, 2 November 2020 17:42:00 UTC