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

XProc Minutes 07 Sep 2006

From: Norman Walsh <Norman.Walsh@Sun.COM>
Date: Thu, 07 Sep 2006 12:11:49 -0400
To: public-xml-processing-model-wg@w3.org
Message-ID: <87d5a71wsa.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2006/09/07-minutes.html

W3C[1]

                                   - DRAFT -

                            XML Processing Model WG

Meeting 34, 7 Sep 2006

   Agenda[2]

   See also: IRC log[3]

Attendees

   Present
           Norm, Paul, Murray, Mohamed, Henry, Alex, Richard, Michael, Andrew

   Regrets
           Alessandro, Erik

   Chair
           Norm

   Scribe
           Norm

Contents

     * Topics
         1. Accept this agenda?
         2. Accept minutes from the previous meeting?
         3. Next meeting: telcon 14 Sep 2006
         4. Review of open action items
         5. Liaison with GRDDL WG?
         6. Technical discussion
         7. Any other business
     * Summary of Action Items

     ----------------------------------------------------------------------

  Accept this agenda?

   -> http://www.w3.org/XML/XProc/2006/09/07-agenda.html

   Accepted.

  Accept minutes from the previous meeting?

   -> http://www.w3.org/XML/XProc/2006/08/31-minutes.html

   Accepted.

  Next meeting: telcon 14 Sep 2006

   No regrets given

  Review of open action items

   A-13-01: Continued.

  Liaison with GRDDL WG?

   Tag, you're it, Murray.

   <scribe> ACTION A-34-01: Norm to send mail to the GRDDL WG chair [recorded
   in http://www.w3.org/2006/09/07-xproc-minutes.html#action01[6]]

  Technical discussion

   Step Container Proposal: ->
   http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Sep/0003.html

   Alex: First, I'd like to introduce the concept of a Component Type
   ... Viewport and other language constructs create their own component
   type.

   Henry: I agree with the idea. Viewports and things like them need
   declare-outputs.
   ... Are there any substantive differences from the UML I sent out last
   week?

   Some discussion of how Alex's proposal and HT's diagram differ

   Richard: Is there a distinction between the signature and the type?

   MSM: If I have two components with the same inputs and outputs, are they
   the same type or different?

   Alex: I think they'd be different because they'd have different names.

   MSM: I'm perfectly happy to say that the name is part of the component
   type.

   Richard: Type and signature seem to cover the two cases here.

   HT: In my diagram, the signature includes the kind so they're the same.

   MSM: I like the word signature without the kind.

   HT: I don't see any need for a signature without the kind, but I'm happy
   to change the name on the diagram

   Richard: We can introduce it as a term that may be useful without having
   an impact on the semantics.
   ... We could say that the connections to a component must match its
   signature.

   <MSM> One point worth considering: it's useful to define terms if they
   will be useful to people discussing the spec, whether they have work to do
   in normative spec prose or not.

   <Zakim> MSM, you wanted to ask whether 'component type' as described in 1
   has anything to do with what actually happens to the data - or is it just
   a signature?

   Richard: Alex, you're proposing that we create subtypes that only have one
   instance.

   Alex: yes.

   <Zakim> Norm, you wanted to point out that the spec currently uses the
   word "signature"

   Norm: We already use the word "signature" in the spec.

   Alex: I'm happy to say that the component type is a signature with a name.
   ... I wanted to have a name for these things like viewport, and for-each,
   etc. that contain steps.
   ... I called them "step containers"

   <richard> I suggest "container step" rather than "step container", to
   emphasize that it's a step

   Norm: I was resistant, because I don't want to make them too special, but
   it will help in the exposition of where bindings can occur.
   ... I sort of like "container step" better

   Richard: It's only one of the aspects of the steps that they're
   containers. They have other specialnesses to them.
   ... In particular, they provide control flow.

   Murray: Can I suggest the word "procedure" as a grouping of steps.

   MSM: There's lots of baggage connected with that term.

   Alex: Maybe we need more terms, but having a term for just the container
   nature seems useful.

   Richard: I agree. It may not be immediately apparent that there's an
   analogy between these control structures and pipelines themselves.

   <MSM> [Would 'compound step' be a useful term?]

   <MSM> [by analogy with 'compound statement' in other pgoramming langauges]

   HT: Pipelines are not in the category of things that a graph is made of.
   I'd rather not give this a name thta's associated with stage.

   Alex: But a pipeline library is for pipelines that you use as steps

   HT: I thought we said that there may be a component that allows you to
   call a component by name, but you can't put a p:pipeline inside a choice.
   ... There are common or garden steps and language constructs which
   assemble into the graph.
   ... We distinguished from that pipelines that are packaging for graphs for
   unitary invocation.
   ... I thought on that basis that pipeline was special.

   <MSM> so is there a name for what you write when you invoke a pipeline as
   a step?

   Yes, MSM, p:step component="pipelineName"

   HT: We need a category for the things you can join up with inputs and
   outputs. Pipeline is not in that category.

   Alex: Pipelines are pretty much exactly like group. One way out of this
   box is to say that a pipeline is an extension of a group.
   ... When you use it in a step you're invoking that group.

   HT: But it may be named, may contain component declarations, etc.

   <MSM> [It seems we are talking about two sets: the set of things that
   contain steps, and the set of things that can go inside a choice or other
   container. Set 1 seems to be equal to Set 2 + {p:pipeline}.

   Murray: Rather than simply saying that it has a lot of baggage, can
   someone explain why "procedure" is not a good choice?

   Richard: I find it anti-intuitive. In other programming languages,
   procedures are the things that aren't syntactic constructs.

   <MSM> [My concern with the term "procedure" is that it suggests to me very
   strongly an association with parameters and arguments, which I think
   doesn't match up very well with these constructs.]

   Richard: In C or Algol, or any of those things, a procedure is something
   you call, it's not a control structure. "If" is not a procedure in any
   language like that.

   Murray: But in everyday language, it is fine.

   Richard: Indeed, but in the context of programming languages, it doesn't
   match very well.

   <MSM> [I think Richard has enunciated another aspect of my concerns, too.]

   Murray: We seem to have trouble sticking with the metaphore of pipelines
   that we've adopted.
   ... In wikipedia, the description of a pipeline includes "processes"
   ... I keep tripping on various english language constructs where there
   seem to be simpler english words.

   <ht> I think 'procedure' would be a good alternative for what we have
   called 'group' heretofore

   MSM: I think that there are two different sets we're talking about.

   <ht> but not for the category including group-as-was and choose and
   for-each

   MSM: One is the set of constructs that can contain other constructs, of
   which the pipeline element is clearly a member
   ... And the other is non-atomic constructs that can occur as constructs,
   of which pipeline is not a member.

   HT: They both need names. One needs input/output decls everytime they're
   used and the other is something that can be connected together.
   ... Stages is the word in the diagram for things that you can connect with
   pipes.
   ... It doesn't have a name for the superclass of things that have things
   inside them.

   Richard: I find Alex's description quite compelling. We need a name for
   things which contain steps and need declarations.
   ... Then we can say that so-and-so is a step container and you know how
   it's connected up.

   <MSM> [The need for the latter is: what can go into a 'when' ? ]

   Richard: In HT's diagram, stage is that plus ordinary steps.

   Alex: I want to observe that pipelines are a lot like a group.

   Murray: Group is a local scope for a set of parameters.

   Norm: Is one of these names the least controversial?

   Step container

   Container step

   Procedure

   Compound step

   Some discussion

   Norm: Step container looks to be a minimally controversial choice

   Murray objects but encourages us to proceed anyway

   We'll go with "step container" provisionally.

   HT: This is the first time where I'm moved to do double inheritence in the
   diagram

   Norm: Where?

   HT: Pipeline and construct are both going to be subclasses of
   step-container
   ... And step container will have a body that is a flow graph
   ... Which is fine, that is actually accurate.

   Norm: I think the rest of Alex's message describes the constraints on
   input/output bindings in terms of what we've just discussed.

   Alex: Yes. We don't say enough about this yet.
   ... This is the point that we had heartburn about at the f2f.

   Richard: Step containers bind their input ports to other steps. Right.

   Alex: The input binding can't be to something inside you.
   ... You could bind to the input of some ancestor.
   ... It might be nice if we could get away from this input/output problem.

   Richard: We bind inputs to sources and sources can either be outputs of
   siblings or declare-inputs of ancestors.

  Any other business

   Alex: I sent out a standard library definition. I think it would be good
   to start writing definitions of the standard components.
   ... I could start with the use cases and put it together in a more formal
   way.

   Norm: Go, man, go!

   Murray: I've come up with another term.
   ... How about a work flow?

   Norm expresses reservations because we're not doing choreography

   Adjourned.

Summary of Action Items

   [NEW] ACTION A-34-01: Norm to send mail to the GRDDL WG chair [recorded in
   http://www.w3.org/2006/09/07-xproc-minutes.html#action01[8]]
   **
   [End of minutes]

     ----------------------------------------------------------------------

   [1] http://www.w3.org/
   [2] http://www.w3.org/XML/XProc/2006/09/07-agenda.html
   [3] http://www.w3.org/2006/09/07-xproc-irc
   [6] http://www.w3.org/2006/09/07-xproc-minutes.html#action01
   [8] http://www.w3.org/2006/09/07-xproc-minutes.html#action01
   [9] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
   [10] http://dev.w3.org/cvsweb/2002/scribe/

    Minutes formatted by David Booth's scribe.perl[9] version 1.127 (CVS
    log[10])
    $Date: 2006/09/07 16:10:09 $

Received on Thursday, 7 September 2006 16:11:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:21:48 GMT