See also: IRC log
Henry wants to talk viewport and for-each (viz comment 83)
Possibly also about comment 94.
Paul gives regrets.
Editor apologizes that it remains incomplete.
Henry: Thinking about this a
little bit reveals a problem because of the schizophrenic
nature of the output decls on viewport/for-each
... Such declarations face both ways, they do two jobs: they tell the viewport semantics where to get the documents to plug into the gaps of the original input doc.
... You need this if you don't want the primary output of the last step in your subpipeline to give you the result.
... That's the content of the output declaration.
... The other thing it does is face outward to tell you things about the output of the viewport itself. In particular, to give it a name so that you can reference it from some other sibling step.
... These two functions are independent and semantically quite distinct, but they're folded together here.
... In viewport, in which direction does the sequence attribute point?
... It only makes sense one way, of course.
... And the same question arises for 'primary', though it seems less significant there.
... For consistency, just as we have a fixed, you can't fuss with it, special input port that faces into the subpipeline, we should have a special output port for the step itself.
... I propose that the spec for viewport/for-each should be changed to make it clear that p:output is only used inside. The output port of the step itself is 'result' and you can't change it.
Richard: That doesn't work for
for-each because for-each can have multiple output ports.
... There are two different output ports in viewport, the output port of the contained subpipeine and the output port of the viewport itself.
... The question is, to which of these do the declarations on p:output apply.
... In the case of viewport, there's always exactly one output from the viewport and its always one document. We should just say that it's always primary.
... Everything in the declaration applies to the contained pipeline.
... This would mean that you can't choose the name of the output of the viewport.
... Why doesn't this problem arise for choose?
... Because after the test, the selected subpipeline replaces the original step. It behave as if just that had the selected pipeline in a group.
... for-each is somewhere in between. It doesn't wrap its output, but it does get concatenated together into a sequence.
... Whereas with choose, if the output of the when is a sequence then the output of a choose is a sequence. In a for-each, the output is always a sequence.
... We want for-each to be able to have several outputs, so we need to be able to specify the names
... Can we say that the output port serves double-duty for both the contained pipeline and the for-each itself.
... AFAICS, we can.
... It couldn't serve double-duty if we wanted them to have different properties.
... But we don't, because the only thing that's different is that we always want the outputs to be sequences.
Norm: Is the following summary correct, for viewport, the step output has the same name, is primary, and is not sequence. For for-each, we say it has the same name, it's primary if you said the inner one was, and it always produces a sequence.
Richard: That's different in one respect, Henry suggested that for viewport it should have a fixed name.
Henry: I hate this aspect of our design. But pretending that there's only one declaration when there are really two just seems very, very odd.
Richard: There's a substantial difference between the viewport and for-each cases. In the viewport case, the result doesn't really have anything to do with what was produced by the steps inside.
Norm: Yeah, ok.
... So for viewport we say the name of the output fixed and is 'result'.
Does that resolve everything?
Richard/Henry: I think so.
Henry: Yes, there's definitely a point here.
Norm: But we do forbid empty pipelines.
Henry: But declare step isn't a
compound step, so that doesn't really apply.
... So we should make that static error apply here too.
... In any event, we need to clarify the case.
Norm mumbles a bit
Henry: The problem is that the implication in the text runs the wrong way. What needs to be said is that the implication runs both ways.
Henry: In 2.1, it used to say
that extension elements had somewhat constrained
... We need to put those constraints in for p:pipeinfo
Henry: There are a bunch of unclosed issues.
Norm: I think they'll be closed when I've implemented the decisions we've made