See also: IRC log
-> http://www.w3.org/XML/XProc/2006/09/07-agenda.html
Accepted.
-> http://www.w3.org/XML/XProc/2006/08/31-minutes.html
Accepted.
No regrets given
A-13-01: Continued.
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]
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.
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.