Agreed: (over-riding yesterday's decision) Syntax/semantics for for-each:
<for-each name="p"> <decl-input name="chap" ref="a!b"/> <decl-output name="out" ref="s2!out"/> <decl-output name="err" ref="s2!err"/> <step kind="xslt" name="s1"> <input name="document" ref="p!chap"/> <input name="stylesheet" source="..."/> </step> <step kind="..." name="s2"> . . . </step> </for-each>
Constraints:
decl-inputdecl-outputsselect="..." on the decl-input, or both)decl-output must have a ref, and it must
refer to an output port of a step in the contained 'pipeline' bodystep, choose or for-each elements(decl-input|decl-output|param),(step|choose|for-each)*
Unclear what happens if there are no steps, what's possible for the decl-outputs
for-each is magic:
decl-input identifies the input for the entire
for-each, and also names the port to which the
contained 'pipeline' body steps can refer for the individual document (the iterator
variable, as it were)Agreed: choose, when and
for-each may all contain param (or
decl-param, issue open).
Lengthy discussion, including a brief recap of the "We don't need this to
be special, you could do it with for-each and a
'splice sequence
in where xpath matches" component'. A fair amount of dissatisfaction with the way in
which the select attr works differently for for-each
(if present on the decl-input) and for viewport.
Agreed:Syntax/semantics for viewport:
<viewport name="p"> <decl-input name="chap" ref="a!b" select="/book/chap"/> <decl-output name="out" ref="s2!out"/> <step kind="xslt" name="s1"> <input name="document" ref="p!chap"/> <input name="stylesheet" source="..."/> </step> <step kind="..." name="s2"> . . . </step> </viewport>
Constraints:
decl-inputdecl-outputsdecl-output must have a ref, and it must
refer to an output port of a step in the contained 'pipeline' bodystep, choose or for-each elements(decl-input|decl-output|param),(step|choose|for-each)*
Unclear what happens if there are no steps, what's possible for the decl-output
viewport is magic:
decl-input identifies the input for the entire
viewport, and also names the port to which the
contained 'pipeline' body steps can refer for the individual document (the iterator
variable, as it were), and also provides (via select)
the pattern which determines what is in fact iterated over.decl-output are plugged
into the original input at the points corresponding to the successive internal inputs to
produce the overall output'viewport' is not universally admired, alternatives are being sought.
'name' or 'port'? Straw poll 2 1/2 prefer each. 'inputPort name=' and 'outputPort name=' also attracted some support. If we use 'name=', we could replace 'ref=' with 'port='.
New straw poll: (in_favour(+2ndchoice), -(can't live with)
Decision postponed. . .
Spec'd and invoked by-name sub-pipelines (i.e. <pipeline> inside <pipeline>
Inline pipeline -- possible problem is that it has to have a name, so
that its output can be refed, but that would encourage invoking the thing
itself. So, we need a nearly-neutral wrapper -- we'll use block
as a working name.
Straw poll, initial list div (1), block (5), steps (2), step-group (3), group (2), let (2), scope (0), wrapper (0), sub-pipeline (1), push (1), begin (2), xh (1), diversion (1)
Final two rounds (2votes/1vote)
Conclusion, use 'group' for now
So, three new constructs: embedded named pipelines, invocation of same, 'group'
Can embed pipelines in the top-level document. Considerable discussion about whether the top-level elt is 'pipeline' or something else, and what was visible outside, and how to support pipeline libraries.
Wrt invocation, we maybe have the following situation: An implementation starts from a set of components and (possibly empty) sets of inputs and parameters. Components come from individual pipeline documents, pipeline libraries (which might be documents, or might be built-in to implementations) and basic component libraries (which are built-in to implementations). Implementations may define a way for users to define components, but that's not required. How to determine what to run: