W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > August 2006

XProc Minutes 17 Aug 2006

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


                                   - DRAFT -

                            XML Processing Model WG

Meeting 32, 17 Aug 2006


   See also: IRC log[3]


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





     * 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


  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,
   ... 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

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

   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
   ... And it appears right at the output port.

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

   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
   ... I've made an attempt to make pictures for the things that we've
   ... 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]


   [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
    $Date: 2006/08/17 20:09:24 $

Received on Thursday, 17 August 2006 20:12:23 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:40 UTC