- 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 UTC