W3C

XML Processing Model WG

Meeting 34, 7 Sep 2006

Agenda

See also: IRC log

Attendees

Present
Norm, Paul, Murray, Mohamed, Henry, Alex, Richard, Michael, Andrew
Regrets
Alessandro, Erik
Chair
Norm
Scribe
Norm

Contents


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]

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]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2006/09/14 17:57:49 $