See also: IRC log
-> http://www.w3.org/XML/XProc/2006/08/17-agenda.html
Accepted.
-> 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.
Cancel 24 Aug, next meeting 31 Aug.
Accepted.
The WG thanks Murray for his wonderful hosting of our F2F meeting.
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.
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.
None.
Adjourned