Norm is late to the call, Henry begins the meeting (thanks, Henry!)

<ht> http://www.w3.org/XML/XProc/2006/09/28-agenda.html

<ht> Agenda agreed

<ht> Accept minutes of previous meeting as a valid record

<ht> Apologies for next week from HST, Norm

<ht> Tentative agreement from MSM to chair next week

Michael: Suggest we do 2 minutes around the table, then discuss

Alex: Pop the whole discussion up several levels
... The level of detail shown in these diagrams is too great to be helpful to readers
... I use that level in my implememntation, but I wouldn't expose it to users
... Maybe we should even just drop all mention of graphs from the spec
... and not constrain implementaitons

<alexmilowski> Clarification: I mean delete the computer science terminology of a "directed acyclic graph"

Murray: Like what Alex said. Move to a higher level. Don't need to talk about graphs.
... Can move this discussion elsewhere.

MoZ: Need to have a formal semantics in the near future.
... Agree we don't need to talk about this now.
... Go further with semantics and models in parallel.
... Don't want to loose focus on semantics.

Richard: I think graphs are great. They're easy to understand and we should have lots of them in the spec.
... But they aren't the semantics. We should have a straightforward semantics written in English.
... They should work in a natural way describing each of the components.
... Don't need to describe the semantics of the whole flow; do it in a modular way for each component.
... We don't need to decide how the diagrams look because they aren't in the semantics.
... They don't even have to be right; they can give the users an idea without mapping onto the semantics.

<alexmilowski> +1 to that !

Richard: It's irrelevant whether or not the pictures are accurate as long as they're helpful to the reader.

Erik: I like what Richard said.

Michael: I'm made nervous by some of what I've heard.
... I think we need two things, or one thing with two aspects.
... 1. We need to understand what we think pipelines are; and 2. we need a story.
... I'm not committed to the graph description as the best or only story
... But at some level it's clearly appealing.
... I'm made nervous about the proposals that say let's not go there, unless they mean let's find another way to reach clarity.
... I worked on a spec 10 years ago that has worked pretty well, and I remember Dan Connolly pushing often to answer the question "what is an XML document".
... I didn't think we needed that kind of clarity; everyone knows what we mean.
... But many of the hardest problems have come from the fact that we didn't answer the question that Dan asked.
... I now think that it would have been useful
... I'm not sure defining a pipeline as a graph is useful, but it may tell a good story.
... My goal here is clarity.
... If we don't say a pipeline is a graph, I want something similarly concise and suggestive.

Rui: I tend to be pragmatic; I agree with Alex and almost everyone else.

Norm: I'm happy to move on to something else for a bit. I'll assume to the extent that people agree or disagree with what the spec says, they'll comment on the words in the spec.
... Sorry I missed what Alex said.

Henry: My experience producing these diagrams: http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Sep/0071.html/
... I started trying to produce diagrams that were faithful to my understanding.
... Convinced me of two things: a lot of detail is necessary and when we state the semantics of the components, it will not be appropriate to try to do so in terms of the diagrams
... We'll want to use words like the spec currently does perhaps with a more explicit abstract model.

<MSM> Henry, can you say a bit more about what kind of detail you found necessary and why it proved essential?

Henry: It did help me understand

Henry: If we look at figure 1a, a nested graph mode of a for-each
... The distinction between thick gray lines and dotted black lines are that the gray lines are the pies and the dotted lines that are the lines of the approrpiate type for the component.
... Documents flow down think gray lines.
... What a dotted line means is context dependent, in 1a the top dotted line means send a single document down this repeatedly.
... The bottom dotted line is the concatenation of the output of all the iterations.
... Now compare with figure 1b

<MSM> and why is it essential to distinguish single-document data flows from multi-document data flows / loops?

Henry: In the computed schema case, I've put the computation outside the for-each
... There is an auxilliary input to the for-each because I need a new kind of connection.
... The dotted line from the XSLT result to the XInclude port. This time the dotted line means repeatedly include the same component.

Alex: This is where we need to pop up a level.
... There are some constraints here, but the schema is not an input to the for-each. It's used inside, so your implementation has to do something about it.

<MSM> At the point where we start saying it's essential to distinguish three kinds of edges, I think we have left any story about graphs behind.

Alex: I think there needs to be a line that crosses the red box. It's not formally an input to the for-each.
... I don't do it that way and it works just fine.

<ht> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Sep/0073.html

Alex: There's a constraint here that you can describe to the user, that the scheme has to be the same each time. You don't have to say that it's an input.

Murray: In fact, isn't the computed schema a pull? It's not a computed input, it's a pull from the validate.

Norm: No, it's not a pull, it's not a URI, it's computed by a previous step.

Alex: That's the kind of clarity we need. It's not something you're iterating over, it's a value that goes along from the ride.

Richard: I don't think we want any diagrams like this in the spec. A diagram with three kinds of lines just isn't useful to a new user.

<alexmilowski> +1 to that

<MSM> +1 to opposition to three kinds of dotted lines

Richard: They're useful to us to argue about what we actually mean.
... OTOH, I think diagrams like the ones currently in the spec, which are much more informal, are what we need.
... I'd like to compare the XML spec to the Schema spec. I don't want this spec to be like the Schema spec where you have to analyze every sentence for meaning.
... There should be a place where the semantics are spelled out clearly. If there are errors there, we should fix them. If there are other descriptions that seem to say something slightly different, that shouldn't matter.
... If in the course of producing the semantics, it turns out to be useful to produce a specialized diagram, we can do so.

<MSM> [I agree with Richard that we don't want readers to have to be language lawyers. But I believe one reason the schema spec is unclear is that we did not insist on clear common understanding of what schemas and schema components are. That means the prose has to avoid saying things clearly, it has to say things obscurely so different WG members can each think it's saying what they mean.]

Richard: (replying to MSM's comment above) I don't think that has anything to do with what's wrong with the Schema spec. It simply tries too hard to be declaritive. It lays things out as discrete declarations instead of providing a place to read from to understand procedurally what validation does.

Alex: I'm looking at things that say, if you used an input inside a for-each that isn't something you're iterating, then it's constant during iteration.

<MSM> [I think part of the reason the validation rules are hard to read is that they aren't in fact declarative, they are an algorithm pretending not to be an algorithm. What the spec needs is more declarativity not less.]

Richard: I think the easiest way to describe this is in terms of the documents produced by ports.
... The fact that there's a line going across a box simply means that this document is used in each iteration.

Alex: It turns out that implementations are going to have to do something to make that work.

Richard: We can simply describe what happens (the component gets that document) without describing how the component achieves that result.

Alex: I wonder if we can try to restate what was going on in the deleted section 4.1.3.
... I think there are a handful of rules that we could say concretely without going into particular implementation semantics.

Henry: The only reason that I'm unsure of our ability to do that is that I'm worried about the cross-product phenomenon.
... The reason for stating things in terms of the auxillary-input story has the advantage that there are no cross-prodcut problems.
... It worries me that it's not going to be the case that if you refer to a port across a choose boundary and say "thus and such"
... Instead, you're going to have to say "if you refer to one across this boundary and that boundary"...
... I can't prove that, but I'm worried that it won't be possible to say things once.

Alex: I think we have two kinds of things we have to worry about, output of regular steps and these "dangling" inputs.

Norm: I'm also worried about the choose component and dealing with branches that don't execute.

Henry: I thought about that too and I'm less worried. Outputs are always produced (crucially), the fact that it's input is plugged into the branch of a choose that doesn't execute can't matter, because the producer of the unused input might have side effects, and they must always happen.

Richard: The flow and pipe metaphor is unuseful in this case. It works much better to explain it in terms of a document being produced and saying that it will be availble if it is executed.

Alex: I think for-each and viewport have a similar but somewhat simpler story. So if we get it right it should work everywhere.
... As a concrete exercise, can we think about those constraints.

Richard: Michael said earlier that conceptualizing this as a graph is very attractive, but it seems to me that it has not so far proved to be a useful way of describing the details.
... In a regular programming language, this sort of problem never arises and that's an indication that perhaps it's not useful here.

Alex: I agree.

Norm: Perhaps that's the highest level take away from three weeks of discussion.

Richard: If we use graphs but they don't map to the semantics, Micheal will tell us we're being misleading, right?

Michael: It depends. I notice that lots of people draw pictures and can't actually tell you what the lines and symbols mean.
... If we have a coherent explanation of what the symbols mean, that might be sufficient.
... If they don't depict graphs, then we shouldn't say they are. We should say they "show the data flow" or something like that.
... There's a distinction between drawing something that is false and something that is a simplification.

Richard: Maybe we should instead say that even if we use graphs as diagrams, we shouldn't use formal graph-theory language in any kind of prose if we aren't intending to be precise.
... Perhaps we shouldn't say that a pipeline is a directed acyclic graph...I'd rather keep the lines and boxes as informal descriptions than to formalize them so that they are consistent with graph theoretic terms.

Michael: It's not entirely clear to me that the complications Henry found it necessary to introduce are in fact necessary.
... If you just say that for any pipeline we can struct a graph with nodes and arcs, that's much simpler. That doesn't draw you a picture of parameter passing or flow of control, but as long as you don't say it does, you're not telling a lie.

Norm describes next steps: changes to the document to remove graph theoretic terms we aren't apparently comfortable with and another to propose areas where the spec needs more prose.

Henry: I'm going to take a stab at writing some class definitions for a few of the constructs.
... To see if the lessons I learned can be expressed in one way or the other.

Alex: I'm going to try to recodify some of my constraints.

Norm: (Planning for next week.) I'll see what develops in email and publish an agenda next Wednesday either cancelling the call or proposing an agenda.

Adjourned

Accept this agenda?

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

<alexmilowski> pre coffee, only partially present...

Accepted.

Accept minutes from the previous meeting?

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

Accepted.

Next meeting: telcon 21 Sep 2006

Possible regrets: Rui

Review of open action items

A-13-01: Continued.

A-34-01: Completed

Technical discussion

Discussion of draft

<ht> http://www.w3.org/XML/XProc/docs/ED-xproc-20060912/#steps

Henry: I'd like to talk about steps and components

Alex: I'd like to talk about 4.1.3

Henry: I'd like to see if we can't reach consensus before the end of this call.

Alex: I'd like to see about fixing my example too.

Henry: Everything up to 2.1 is fine except that figure 2 needs a transform step at the end, not a validate step

<MSM> also s/rerpesents/represents/

<scribe> ACTION: Norm to fix figure 2 [recorded in http://www.w3.org/2006/09/14-xproc-minutes.html#action01]

<MSM> also s/Definition: A step which contains other steps is called a step containers./...container./

Henry: Steps ought to be bits of markup; but we talk about step containers which ought to be about components
... All of sections 2 and 3 don't need any notion of representation or anything like that
... The introduction of the notion of representation and the XML level in section 2 is a mistake and you don't stay with it.

Norm tries to explain his view

Norm: Steps are syntax and some of them have steps inside them. Components get instantiated and some of them contain subpiplines.

Henry: Maybe we can just try to write the first two sentences of 2.1 without saying anything about pipeline documents or represents
... You've chosen "component" as the over-arching term.
... Some components are atomic like xslt and atomic and others are "constructs" or "step containers"
... Except that we have components now so they ought to be component containers.
... Many components are simple and atomic and correspond to a single operation. An XSLT component, for example...
... However, some components are containers for other components...called a container...called contained components

Alex: Step and step container is still an abstract concept, it's not just markup.
... Component is something that has to be bound and has to have all that information.
... I'm not sure that drawing an analogy between the language constructs and a component is the right thing.
... Components containing components seems awfully technical, do we really need to go there?

Henry: I like the way the first section reads

<MSM> if a pipeline is a DAG of (atomic) components, then we've got: graphs, subgraphs, and nodes

<Zakim> MSM, you wanted to suggest that the absence of a definition of 'step' is symptomatic of a problem. I'm not entirely certain which problem. But a problem.

Michael: I have an unease similar to Henry's: as a first time reader, I can't tell if step is an abstract unit that may correspond to a subgraph or an XML thing (or both). And so I agree with Henry that there's room for improvement here.

<ht> So, Alex, note in section 1 we have "The standard “choose” component evaluates"

<ht> which reads just fine to me

Michael: Unfortunately, Henry's proposal has a contradition: either components nest and they're similar to blocks in Algol style programming languages *OR* pipelines are DAGs of components.

Henry: I've come to think that that's not the best way to think about these things.
... At the same time, a component container is a node in one graph and has a graph inside it.

Michael: Then the definition of pipeline as "a graph" is misleading.

Henry: Look at figure 2. The Choose box contains a subgraph.
... There are important constraints that are captured naturally by saying that the nodes are either atomic or contain subgraphs.

Michael: Then we should say that the graphs inside are separate.
... Let's talk about it in sort of purely graph terms. I think there are two ways to tell the graph story.
... One way is to say that the graphs are contained inside and don't connect.
... Another way is to say that there is a graph that has all the components in it. The way to view choose is a subgraph of that larger graph.
... If we think of it in terms of the latter approach, then the drawing here is not the flat graph either. You need a splitter node and ajoiner node as well.
... Steps then always correspond to subgraphs; atomic steps just correspond to a single node.

<Zakim> alexmilowski, you wanted to modify that definition of subgraph

Norm: I prefer the former definition.

Alex: I prefer the latter.
... My model is that there is a single graph. I think of choose being a node in the graph.

<Zakim> ht, you wanted to point back to the agreement from Ontario

Henry: I'm happy with the first story. I don't understand the second yet.

http://www.flickr.com/photos/ndw/211253174/in/set-72157594234207396/

Henry: Having the language constructs like choose and for-each be a locus of ports (of nodes in the graph) and a scope all seem to work well together.
... It must be the case in some sense that the stories are isomorphic, but I think the story that's in the document is much closer to the first story.

Norm proposes to talk about 4.1.3 for a bit as it seems directly relevant to which story we're telling.

Alex: What happens when some contained step points off to something that it's allowed to access.
... In 4.1.3 we say that we have some fabricated declaration.
... It's going to be a mess to report errors.
... It's not helpful to make this thing self contained.

Norm and Alex go back and forth a bit about what the right answer is.

Alex: I see two ways out of this, allow declare input and actually make 4.1.3 valid against our current specification and acknowledge that people can do this. Or have a different model for how we talk about these things.
... There's an inconsisentency here that bothers me.
... There's a problem with for-each and view-port where you'd have to be able to tell *which* for-each was the important one and which are the others.
... Maybe it would be better to draw a picture.

Norm: I propose dropping 4.1.3 for FPWD

Alex: I'd be happy with that, perhaps with the ednote placed somewhere else with more explanation

Resolved, we'll drop 4.1.3 for FPWD

<MoZ> +1 but letting know that the WG will propose shortcut syntax

Henry: My feeling is that I don't care if we don't settle this question in this WD either.
... I'd like to see slightly more consistency in the story we tell in parts 2 and 3.
... I'll volunteer to work on a new draft over the weekend.

Proposal: The WG will publish the current draft as the FPWD (with 4.1.3) removed.

So resolved.

<scribe> ACTION: Norm to request permission to publish [recorded in http://www.w3.org/2006/09/14-xproc-minutes.html#action02]

Proposed: If an alternate draft is proposed by close-of-business (Boston time) on Monday, the WG will have until close-of-business Wednesday to veto. If there are no veto's, the alternate draft will be published instead. The only plans for the alternate draft are to improve wording in sections 2 and 3.

Accepted.

Proposed publication date: 28 Sep 2006

Accepted.

Any other business?

None.

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.

Accept this agenda?

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

Accepted.

Accept minutes from the previous meeting?

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

Accepted.

Next meeting: telcon 7 Sep 2006

No regrets given.

Comments on the draft

Four things: add a description for p:declare-parameter

scribe: Document select on p:param (we need to determine the context)
... Remove the special case in 4.1.1 for a source w/o step
... Add text about extension attributes and elements
... Do we allow p:declare-input on for-each, choose, etc.

Henry: We've talked about components and steps as quite different things
... in the draft, you've moved the other way. Now there are just classes of components.
... I think that's a good idea, but I don't think we decided it.

<alexmilowski> I've always thought of it that way too...

Henry: In that case, we need to speak of allowing users to create classes of components

Richard: I think the draft is confusing, it speaks of a graph of components, but choose and for-each aren't described as components.

<ht> HST likes 'construct' for the language constructs

<ht> and 'component' for XSLT and user-defined stuff

<ht> and 'step' for the union of the two

Norm describes how in fact he thinks "for-each" is now in fact a component

Micheal: I'm a little concerned about losing the distinction between steps and components.
... Personally, I believe that people have a tendency to get confused about class/instance distinctions.

Norm describes pipelines as a graph of components and steps as a mechanism for instantiating those components.

Michael: I've got a pipeline with three XSLT stylesheets applied in sequence. I think I have three XML constructs in the XML description of the pipeline. I think I have three steps/stages in an abstract description of the pipeline.
... and three control blocks in memory, but perhaps only one copy of the processor if it's renetrant. But I have one of something, what is that?
... I had thought that that was a component.

Richard: A shell script may run a sequence of two or three programs and two of them may be the same.
... The fact that in the first case I meant programs and in the second I meant executable file doesn't seem confusing.

Michael: In some contexts, I can certainly imagine getting confused if we didn't have conventions for distinction between those things.

Richard: One reason I don't want to elaborate a whole set of names is because there is in fact at least a third case for each one. Suppose you run a pipeline twice. Now, not only are there are the layers we already had, there's also the instances of them running.

Henry: And this is entirely parallel to any description of an OO system.

Richard: There's also the fact that we have constructs that run a component repeatedly within the same pipeline.

Alex: Do we have to dig that deep?

Richard: Let's look at it from the other end.
... We seem generally happy with the term "step" for the things that aren't built into the language.
... We need something for both language constructs and things not built into the language.

Michael: You'd rather say we plug the output ports of the X component into the input ports of the Y component. Why not step?

<MSM> one syllable vs three syllables

Richard: The only reason I don't want to use step there is because we have a step element in the language.

<ht> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Aug/0095.html

Norm describes his situation where components are synthesised sometimes

<ht> See above for the diagram Richard just referred to

Richard: I also want to be able to be able to have steps in the document correspond to single components in the semantics

Henry: The only thing worth noting right now about the diagram is that it goes backwards wrt the current discussion. It uses step for the union.

Michael: I continue to be a little concerned about the absence of a term for the abstraction who's most obvious instantiation is a software module that a user might add to an available library
... what I'm hearing people say is that they want to use "component" for one of the constiuent parts of the pipeline
... I don't have a particular desire to use component in a slightly different way. I just don't think of invocations as instances of programs.

Richard: Defining a component, writing a component, is like defining a function. So XSLT would be a function that you called.
... A line of the program that called that function would be a "function call"
... And there would be other constructs that weren't function calls like conditionals and loops.
... In our language, "steps" are like function calls because we don't call the conditional things steps.

Henry: The problem with "step" for "statement" is that we have have an element named "step" which is the equivalent of "function call"

Norm proposes to try to use step and component consistently in the document and see if that helps

Michael: When CMS pipelines were introduced, the authors thought hard about the terminology.
... They used the term "stage" for the things that go between the pipeline characters.
... and for the processes that get connected up.
... I think in the abstract that step would be nicer, but stage does not have the collision with the usage of step as something which invokes something like XSLT

The select attribute on p:param

Norm summarizes the current state of the document

Norm: I think we need to allow source/href/here on p:param

Alex: I thought we agreed to do that, even though it gives me heartburn.
... I was surprised not to see that in the document.
... I think we should be clear that if you create a param that uses an input that isn't otherwise an input to the step, you're creating a new input dependency.

Richard: It's easy to statically determine what the dependencies are.

Norm will update the document to allow p:param elements to specify a context for the select attribute.

Henry: I expect in due course that we'll have a shortcut for this.

Norm asks about allowing declare-input on p:choose, p:for-each, etc.

Richard: What about a declare-input that you don't use?

Norm: Uhm

Richard: It doesn't seem to usefully document anything if you can't prevent dangling inputs.

Norm: Does anyone else want to be able to declare those inputs?

Murray: I don't see any reason not to

Richard: But unless we have rules that say that if you declare one, you must declare them all.

<ht> MSM, see http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Aug/0096.html for an attempt to follow up your suggestion wrt 'Stage'

Richard: The effect of declare input is simply to alias an existing name. So how come you're only allowed to use it in these particular places.
... My inclination is not to allow it unless we work out what's allowed.

Norm: My middle ground is to say that a declare-input that you don't use is an error.

Henry: I feel that you should minimize the amount of work on the draft in this area.

Norm: Ok, we'll leave it alone, but not record that as a decision.

Norm proposes revising the draft before next week in an effort to get FPWD out

Accept this agenda?

-> http://www.w3.org/XML/XProc/2006/08/17-agenda.html

Accepted.

Accept minutes from the previous meeting?

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

-> http://www.w3.org/XML/XProc/2006/08/03-am-minutes.txt

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

-> http://www.w3.org/XML/XProc/2006/08/04-am-minutes.txt

-> http://www.w3.org/XML/XProc/2006/08/04-pm-minutes.txt

Accepted.

Next meeting

Cancel 24 Aug, next meeting 31 Aug.

Accepted.

The WG thanks Murray for his wonderful hosting of our F2F meeting.

Allow input declarations? Implicit input declarations?

Norm: Users are allowed to refer to inputs outside of for-each, choose, etc.
... I think it would be more convenient if this was done by implicitly inserting declarations.

a

Alex: You're proposing that from the graph-dependency perspective, the way to interpret these constructs is that those dependencies exist.

Murray: I think it would make more sense to me if I read that you could put them in, but you didn't have to. If you put them in, this is what it means, if you don't, it infers them.

Henry: I'm inclined to go further and say that defaulting an optionality are for the next WD. Let's make them required now.

Alex: These don't seem quite the same kind of defaulting to me.

Murray: The way we left things is that there were no declarations. Norm wants to act as if they were there. I'm suggesting we go further, but we make them optional so that we effectively have the status quo.

Mohamed: I was just thinking that it's the same problem as scoping. Do we have to handle the problem as a whole, or just inputs.

Richard: I think that I'm slightly dubiuos about this. For a start, you're doing it for inputs but you haven't suggested doing it for parameters.
... You could say that everything that introduce a scope would be required to copy all the inputs and variables.

Murray: I think this gives a simpler story about pipelines.

Richard: I don't object, I just think that if this is an instance of a more general scoping problem, and we wouldn't necessarily want to do it all this way.

Henry: I think these are different, and I don't mind if we have two different mechanisms.

Norm will write the draft that way.

Treat multiple references as an implicit tee?

Norm: The second question has to do with pointing multiple pipes at the same port.
... I'd like to imply a "tee"

Richard: if two things inside refer to the same port inside and outside, are you going to say where the "tee"s occur?

Alex: I wonder if we can talk about this in terms of infoset instances instead.

Richard: We did decide that we were having copy semantics.

Alex: Then we'd have to say explicitly where all the "tee"s have to go.

Richard: I think it would be very worrying if it turned out not to be equivalent to the "tee"

Henry: I don't see what this is buying us and it's costing us considerably.
... Can't we just say "no side effects" (copy semeantics or whatever you call it) and well-formed graphs have the property that there can be one input and any number of output connections.
... I see no value whatsoever in saying in a fully articulated picture that you have to have tee components.
... This will be confusing and give rise to useless discussions like this one.

Murray: Taking things one at a time. Anyone who's done any plumbing knows what a "tee" is.

<Zakim> ht, you wanted to disagree about T

Murray: The value of having a tee is that it allows me to do some renaming, so I can divide it up in my pipeline.
... What Norm is suggesting is that every output is a virtual manifold. You don't have to have all these different names.
... Henry pointed out that we need rules about what can appear on an output port.
... I see what Norm's suggesting as a manifold and as many pipes as can hook up to it as they want. And you can create a manifold yourself, if you want.
... And it appears right at the output port.

Richard: You mentioned that we had agreed to have arbitrarily many outputs.

Some discussion of whether or not a component can have an arbitrary number of outputs.

Henry: Do we have runtime multiplicity.

s/multiplicity? We don't have a use case yet, I don't think/

Henry: I come back to saying that we don't have a requirement for naming multiple identical outputs.

Alex: The tee component is the case we haven't discussed yet.

Murray: Use case: I've got a book and my first step is to validate it, then I have steps 2a, 2b, 2c, and 2d. Each is going to create a rendering.
... They're all getting their output from step 1.

<ht> But why not have them all refer to 1!output

Murray: We could put a component in between steps 1 and 2a-d, to put it on four separate ports. Or we could leave that step out and all refer to the output of step 1 by the same name.
... What this does is allow you to point to the port with one name.

Norm: I wanted it to make the ports to pipes 1:1. But we need to solve the multiple output problem first.

Richard: I like the idea, but I'm not sure we're ever going to need it.
... One of the things you could do with a tee is subsume other things (a sink, port renaming, etc.) but I think there are other ways to deal with those problems.
... Port renaming doesn't make any sense anyway since you have to point to the step by name.
... You might have to rename steps, but tee doesn't help with that.

Norm: I'm satisfied that we don't need to do any of this for the FPWD.

Henry: I have found some of our conversations difficult to work with because people are discussing naming proposals in terms of "lets use this name for that name" where "that name" is just part of other naming proposals.
... I've made an attempt to make pictures for the things that we've agreed.
... Hopefully, by pointing at bits of the picture, we can say unambiguously what we're talking about.

Any other business?

None.

Adjourned

Accept this agenda?

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

Accepted.

Accept minutes from the previous teleconference?

-> http://www.w3.org/XML/XProc/2006/07/20-minutes.html

Accepted.

Next meeting: Face-to-face: 2-4 Aug 2006

Make sure your arrangements are in order.

Review of open action items

A-23-02: Richard to write a syntax proposal

<scribe> Withdrawn.

A-13-01: MSM to draft a complete table; ETA: 20 July 2006

<scribe> Continued.

Agenda for the f2f

Proposed:

1. Finish the syntax wrangling

2. Define the core language constructs

3. Make a first pass at identifying a list of required components

4. Make a list of standard but optional components (if any)

5. Review our open issues

Norm will try to draft an agenda this week

XProc syntax

Lots of good discussion on the list, any burning issues?

None suggested.

Alessandro's proposal:

<Alessandro> http://avernet.googlepages.com/xproc-syntax

Alex suggests looking at for-each

Alessandro: On the for-each it looks like we want to reference a sequence of documents that we want to iterate on, we want the option of providing an XPath expression.
... In the for-each we need to be able name the outputs

Norm did something alternate:

-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Jul/0138.html

Alex: If you're iterating over a document and using an XPath expression, you have to specify a replacement
... When you're iterating over a sequence of documents, that's not necessarily true.
... There are way more options when you're iterating over a collection of documents.

Some discussion of whether we're talking about for-each or peephole

Norm tries to outline how for-each and peephole differ. For-each just returns the sequence of things generated, peephole wraps the original document around the replaced matches.

Richard: I think there should be something that does a body for each document in a sequence and something else that does each matched part in a single document.

Norm: We could have for-each and for-each-document, I just didn't think it was necessary.

Richard: The output is a sequence of documents. The peephole mechanism can be build out of that, I think.
... A component that takes the original and an XPath and a sequence of documents, the sequence could be plugged in where the matches occurred.

Alex: It could be done that way, but I'm not sure I want to do it that way.

Norm wonders if there's a practical use for a component that works that way.

Richard proposes that there are some uses, whether they're practical or not...

Some more discussion of how for-each and peephole are similar.

Richard: Do they between them cover all the looping functionality we need?

Alex: Can we add a peephole/viewport element?
... I don't much like "peephole".

Norm: Anyone like peephole better than viewport?

Murray: I don't like either.

-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Jul/0138.html

Norm asks about for-each-output and observes he tried to show how declare-output could be used in each case.

Norm: On the subject of name, I assume we're still sort of evenly divided about how we want to do the naming.

Yeah, pretty much.

Richard: On for-each, the name attribute is used for the binding. Does that make it a variable?

Alessandro: Yes.

Norm: Huh?

Alessandro: No, actually, it's just used when you want to ref= to the output.

Murray: I don't understand why we have ref= and href=

Norm: I think we might be able to combine them.

Some discussion of the direction things flow

Alessandro: In my example, the direction is the same

-> http://avernet.googlepages.com/xproc-syntax-parse-import

Norm: I see, the name is repeated. This really only works in the case where you name individual outputs.
... If you were using the compound naming system, then each when would have to have a *step* with the same name and that step would have to have an output port with the same name, in order to make this work.
... So if we go with #name/port it's much harder to always point from the output to the input in the conditional case
... (Where "much harder" means "impossible", I think)

Richard: When I was thinking about conditionals, I was going to have each of the when's declare their outputs.
... Then the choose referred to those names.

Norm: Yes, that would work as well, but it's pretty verbose to have to declare all the outputs on every branch.

Scribe apologizes for failure to capture several minutes of minutes...

Murray: Can't the p:when's output bubble up?

Norm: Not when there's more than one output from the p:choose

Richard: But when there is only one, we might be able to abbreviate it

Norm: Yes, and it's the idea of abbreviations in the future that makes me have a slight preference for the compound naming choice.

Any other business?

None.

Adjourned.