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