XML Processing Model WG

Meeting 32, 17 Aug 2006


See also: IRC log


Norm, Mohamed, Alex, Alessandro, Richard, Paul, Henry, Andrew, Murray, Michael[xx:37-]


Accept this agenda?

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


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


Next meeting

Cancel 24 Aug, next meeting 31 Aug.


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.


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?



Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2006/08/31 20:12:57 $