- From: Norman Walsh <ndw@nwalsh.com>
- Date: Thu, 17 Jan 2008 11:55:18 -0500
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <m2prw05r49.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2008/01/17-minutes
W3C[1]
- DRAFT -
XML Processing Model WG
Meeting 98, 17 Jan 2008
Agenda[2]
See also: IRC log[3]
Attendees
Present
Norm, Paul, Alessandro, Henry, Rui, Richard, Andrew, Alex, Michael
Regrets
Chair
Norm
Scribe
Norm
Contents
* Topics
1. Accept this agenda?
2. Accept minutes from the previous meeting?
3. Next meeting: telcon 24 January 2008?
4. Review of most recent editor's draft.
5. Viewport and for-each
6. Issue 94
7. Editor's draft review
8. Any other business?
* Summary of Action Items
----------------------------------------------------------------------
Accept this agenda?
-> 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.
Accept minutes from the previous meeting?
-> http://www.w3.org/XML/XProc/2008/01/10-minutes
Accepted.
Next meeting: telcon 24 January 2008?
Paul gives regrets.
Review of most recent editor's draft.
Editor apologizes that it remains incomplete.
Viewport and for-each
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.
Issue 94
-> 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.
Editor's draft review
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.
Any other business?
Henry: There are a bunch of unclosed issues.
Norm: I think they'll be closed when I've implemented the decisions we've
made
Summary of Action Items
[End of minutes]
----------------------------------------------------------------------
[1] http://www.w3.org/
[2] http://www.w3.org/XML/XProc/2008/01/17-agenda
[3] http://www.w3.org/2008/01/17-xproc-irc
[7] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[8] http://dev.w3.org/cvsweb/2002/scribe/
Minutes formatted by David Booth's scribe.perl[7] version 1.130 (CVS
log[8])
$Date: 2008/01/17 16:53:55 $
Received on Thursday, 17 January 2008 16:55:31 UTC