W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > January 2008

XProc Minutes 17 Jan 2008

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 17 January 2008 16:55:31 GMT