p:select step? p:xpath?

[ndw]

Consider this pipeline:

<p:declare-step xmlns:p="http://www.w3.org/ns/xproc"
                xmlns:xs="http://www.w3.org/2001/XMLSchema"
                version="3.0">
<p:output port="result"/>

<p:variable name="result" select="count(collection())"
            collection="true">
  <doc1/>
  <doc2/>
</p:variable>

<p:identity>
  <p:with-input select="$result">
    <p:empty/>
  </p:with-input>
</p:identity>

</p:declare-step>

The purpose of the variable is to do some expression on a sequence of documents, I'm using count() which is trivial just so there's a concrete example. The challenge is to get the result, 2, into a document flowing through the pipeline.

You might think the output of this pipeline is "2" but it isn't. There's no input to the identity step so the select expression is never evaluated, so this pipeline fails because result isn't allowed to return a sequence (empty in this case).

You can do this:

<p:identity>
  <p:with-input select="$result">
    <irrelevant-context-document/>
  </p:with-input>
</p:identity>

but that really seems like a hack.

You can't do this:

<p:identity>
  <p:with-input select="count(collection())">
    <doc1/>
    <doc2/>
  </p:with-input>
</p:identity>

because that's going to apply the expression twice, once for each document. The default collection isn't going to be what you might think it is.

Am I overlooking something obvious?

Assuming I'm not, I wonder if this warrants a step which takes an expression (as an option), a sequence of inputs to act as the context, and possibly a namespace context, and produces the result of evaluating the expression on its result port.

[xatapult]

Yes, I had this situation a couple of times.

VNext?

[ndw]

The real problem here is that you want this to work:

<p:variable name="a" select="3"/>
<p:variable name="b" select="4"/>

<p:xpath select="$a + $b"/>

And that doesn't work because select is an option on a step, the expression is evaluated by the step, and the step doesn't have access to in-scope variables. This "works":

<p:xpath select="{$a} + {$b}"/>

But only by making a and b into strings. So if you wanted to do something with a more structured data type, I think you'd run into problems.

In private correspondence, @xml-project pointed out that a text value template in a p:inline is a plausible fallback:

<p:identity>
  <p:with-input>{$result}</p:with-input>
</p:identity>

Maybe that's a good enough workaround. If we don't want to grasp the nettle of some new kind of step that has access to all the in-scope variables, I expect that p:xpath step is more trouble (and more confusing) than it's worth.