See also: IRC log
-> http://www.w3.org/XML/XProc/2008/01/17-agenda
Accepted.
Henry wants to talk viewport and for-each (viz comment 83)
Possibly also about comment 94.
-> http://www.w3.org/XML/XProc/2008/01/10-minutes
Accepted.
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.
-> http://www.w3.org/XML/XProc/2007/09/lastcall/comments#C094
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
semantics.
... We need to put those constraints in for p:pipeinfo
Norm: Yep.
Henry: There are a bunch of unclosed issues.
Norm: I think they'll be closed when I've implemented the decisions we've made