- From: Norman Walsh <Norman.Walsh@Sun.COM>
- Date: Thu, 17 Aug 2006 16:11:39 -0400
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <87bqqjf7gk.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2006/08/17-minutes.html
W3C[1]
- DRAFT -
XML Processing Model WG
Meeting 32, 17 Aug 2006
Agenda[2]
See also: IRC log[3]
Attendees
Present
Norm, Mohamed, Alex, Alessandro, Richard, Paul, Henry, Andrew,
Murray, Michael[xx:37-]
Regrets
Rui
Chair
Norm
Scribe
Norm
Contents
* Topics
1. Accept this agenda?
2. Accept minutes from the previous meeting?
3. Next meeting: telcon 31 Aug 2006
4. Allow input declarations? Implicit input declarations?
5. Treat multiple references as an implicit tee?
6. Any other business?
* Summary of Action Items
----------------------------------------------------------------------
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
Summary of Action Items
[End of minutes]
----------------------------------------------------------------------
[1] http://www.w3.org/
[2] http://www.w3.org/XML/XProc/2006/08/17-agenda.html
[3] http://www.w3.org/2006/08/17-xproc-irc
[10] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[11] http://dev.w3.org/cvsweb/2002/scribe/
Minutes formatted by David Booth's scribe.perl[10] version 1.127 (CVS
log[11])
$Date: 2006/08/17 20:09:24 $
Received on Thursday, 17 August 2006 20:12:23 UTC