XProc Minutes 12 Oct 2006

See http://www.w3.org/XML/XProc/2006/10/12-minutes.html


                                   - DRAFT -

                            XML Processing Model WG

Meeting 39, 12 Oct 2006


   See also: IRC log[3]


           Paul, Rui, Alessandro, Norm, Mohamed, Murray, Henry, Richard,
           Andrew, Michael





     * Topics
         1. Accept this agenda?
         2. Accept minutes from the previous meeting?
         3. Next meeting: telcon 19 Oct 2006
         4. Review of open action items
         5. Technical agenda
         6. Any other business?
     * Summary of Action Items


  Accept this agenda?

   -> http://www.w3.org/XML/XProc/2006/10/12-agenda.html

   Accepted, with Murray's addition of order of processing per the GRDDL WG

  Accept minutes from the previous meeting?

   -> http://www.w3.org/XML/XProc/2006/10/05-minutes.html


  Next meeting: telcon 19 Oct 2006

   No regrets given.

  Review of open action items

   Completion of table in requirements document; continued.

   <scribe> New ETA: November, 2006

  Technical agenda

   <scribe> Continued discussion of scope of step names

   Norm wonders if there was any consensus on scope of step names. None

   Richard observes that the discussion went off on a tangent.

   Richard: If you want to limit what ports can be connected, there are two
   ways: by limiting the scope of the names, and the other is by having other
   ... The scope of step names is not necessarily the same as what
   connections can be made.

   Norm wonders about the ambiguity of step names if you don't use scope of
   names to determine connections.

   Richard: Right, you need to determine what names are in scope and say
   something about ambiguity.

   Norm: Anyone want to do it by some other mechanism?

   Richard: Scope of step names might not be sufficient in the following
   case: suppose that there was some construct such that you were allowed to
   connect to things in your grandparents but not your parents.
   ... You would want to maintain the names in scope so that they could be
   passed through, but that would not be the constraint you'd want to use for

   Norm: I don't think it would be a problem if such a component was not
   possible in XProc.
   ... WRT to scope of names, the only open issue is whether or not the order
   of siblings matters.

   <MSM> [MSM responds, much delayed, to Norm's question - no objection to
   trying to solve these problems by describing scope, but whether it works
   or not depends on how simply we can do it. If we can't describe the scope
   simply in XML terms, then either we need a different way to solve the
   problems or we need to change the scope rules.]

   Norm: Are there others?

   HT: I think the constraints should be stated at a level of abstract
   ... So the notion of order doesn't arise.

   Norm: We could specify that the order matters.

   HT: We haven't yet imposed an order and I don't want to change that.

   <Zakim> MSM, you wanted to say no, concrete syntax

   MSM: I'm made nervous by the assertion that we should specify it at the
   level of an abstract syntax.
   ... We should do it at the level of the conrete syntax. I don't think that
   prevents what Henry wants.
   ... I think we get a better design if we describe things in terms of the
   concrete syntax.
   ... The discussions of programming languages last week illustrate the
   utility of saying there's an XML document and there are the rules.

   Richard: I think requiring the concrete syntax to have no forward
   references is very inconvenient.
   ... If you have a number of conceptually independent threads that pass
   things back and forth, then you can't write them in the natural way.
   ... You have to interweave them in data-flow order.
   ... I wrote a language that didn't allow forward references and I now
   think that was a mistake.

   Norm: Am I the only one interested in assigning semantics to step order?

   MSM and Murray express indecision.

   HT: We can reconsider this if we decide that it would be valuable to
   impose a significance.

   Norm says "uncle"

   Norm: Coming back to the question of scope of step names.

   <ht> HST sure plans to appeal to element order when we (if we ever) get to
   talking about defaulting

   Norm: for inputs, the output ports of ancestors and their siblings are in
   ... also outputs of siblings are in scope.
   ... for outputs: the output ports of children are in scope.

   Richard: do you consider the iteration port of for-eachs to be output

   HT: Not the right question.
   ... What about the declared input ports of the for-each

   Richard: I meant the port that has each document in turn

   Norm: Right, for inputs, I left out, inputs of your ancestors.

   <ht> The WD says: "The scope of component names is the flow graph of their
   container and the flow graphs of the constructs therein, recursively."

   <ht> replace 'flow graphs' with 'children', and it works

   <MSM> [I tend to think that if we are going to have a convention, it may
   be better to say 'the reader always says where its input comes from" or
   "the writer always says where it goes" -- rather than "the upper one looks
   down" or "the lower one looks up"

   <ht> MSM, I agree, for binding -- we haven't changed that for a long time
   -- it's inputs that state their bindings

   Richard: I was trying to avoid this by saying that the ports are a context
   that gets passed along.

   <ht> ... what we're discussing is how we decide what they can see, and
   Richard has advocated doing _that_ 'top-down'

   Norm: I think we all agree, except that maybe we should stop trying to do
   it on the call.

   HT: for inputs, you can look at the declared inputs of your ancestors and
   the outputs of your siblings and your ancestors siblings.

   Richard: Why are you saying that its different for input ports and output

   Scribe is confused

   The thrust being that you could put an identiy component in the for-each
   and thereby make an input into an output.

   Murray: The output of a group has to come from somewhere inside the group.

   Richard: That's the normal case, but it doesn't have to be the case.

   Murray: Right, and you just described how that could be done in the
   unusual case.
   ... But if an output can only refer to what happens inside the container,
   then you've bound it and those are simple rules that I can understand.

   Norm: from an ease-of-use perspective, I think it should come from the

   <MSM> [comprehensible, yes, but very puzzling]

   Norm expresses concern about the complexity of describing this.

   HT: I think that depends on how you describe the situation. The reason I
   like the way Richard is doing it is because it doesn't involve a
   discussion of ancestors.
   ... All you have to do for Richard's approach is say what ports are
   visible to its children.
   ... Works for me.

   <scribe> ACTION: Norm to attempt to write this up in the spec. [recorded
   in http://www.w3.org/2006/10/12-xproc-minutes.html#action01[6]]

   Norm: Moving on to a discussion of parameters.
   ... I think we need computed parameters.

   Alex: I was moved by Jeni's examples, but I'm still on the fence.

   Norm: I thought the manifest case was a slam dunk.

   Alex: You could use viewport.

   Norm isn't sure how.

   Alex attempts to describe this, but the scribe doesn't understand.

   Alex: We need to be able to compute parameters from static values, but I'm
   not sure we need to be able to compute them from inputs.

   <ht> HST notes that if we did have such a builtin step, we could implement
   XInclude with it!

   Richard: Computed parameters are pretty much like the use of backquote in
   the unix shell.
   ... Though there are lots of pipelines that work without it, there are a
   lot that are much clearer if you use backquote.
   ... It's true that a lot of these things that can be done with XInclude
   and such, but everytime we add a parameter that can't be computed, we've
   made things hard for users.
   ... I think people are going to want this sort of thing and it's just too
   messy to have to do it by other means.

   <Zakim> ht, you wanted to quote the WD and to agree we need a
   load-from-input, but not computed parameters

   HT: I'm of two minds. I'm prepared to go some way down the line of
   designing a computed parameter mechanism. But if it looks like it takes
   more than a couple of hours, I want to dump it.
   ... This looks marginal to me. One is to go along the lines we were
   discussing in Ontario.
   ... The other is to introduce one and only one new construct which binds
   any number of parameters to the values of XPaths from one of its ports.
   ... Like a group, but with the ability to bind parameters from a document.
   ... I think maybe the latter would be simpler to spec and understand.
   ... My net net is it's useful but I'm not sure it makes the 80/20 cut.

   Alex: I thought that p:group had to do with scoped parameter bindings.
   This was directed related to the sort of nesting I put in smallx.
   ... One of the main reasons for group was to bind and compute parameters
   for a whole group of things.

   <ht> HST remembers 'bind' for group, but not 'compute'. . .

   Alex: If we can't do that on group then it seems pointless to have.

   Norm: They're just new edges in the graph.

   Alex: I just don't think that works.

   Richard: Why not?

   Richrad: If you have a piped to b and b has a backquoted parameter,
   there's no reason why a depends on the backquoted parameter.

   Alex said something the scribe didn't catch

   Richard: Conceptually, all the inputs and parameters are there when the
   component starts. If it's possible for the component to stream by not
   waiting, that's just an optimization.

   Alex: What's being suggested would ruin a lot of optimizations.

   Murray: When we're talking about a group, a group has a bunch of
   declarations and steps inside.
   ... I consider the declarations part of the group and they happen first.

   <ht> +0

   Murray: When we come to a wrapper, there's something that happens before
   the steps inside get executed.

   <MSM> [Alex's point seems to me quite clear if you ask "Can I compile a
   pipeline specification down to some binary form, and what is involved in
   that, and in running the compiled pipeline?" -- in that context, having
   all parameters be literals, not computed, clearly makes a potentially huge

   Murray: In that case, if parameters are being set before the steps are
   run, that satisfies Alex doesn't it?

   Richard: But Alex wants to stream.

   Murray: I support computed parameters. The question seems to be should we
   do it now or in a future version?
   ... Why not now?

   <MSM> [If we are committed to a highly dynamic language suitable for
   interpretation but less suitable for compilation, then computed parameters
   are clearly useful. -- If we want to be able to compile things, then they
   look like poison to me. I don't know whether that is Alex's point or not.]

  Any other business?



Summary of Action Items

   [NEW] ACTION: Norm to attempt to write this up in the spec. [recorded in
   [End of minutes]


   [1] http://www.w3.org/
   [2] http://www.w3.org/XML/XProc/2006/10/12-agenda.html
   [3] http://www.w3.org/2006/10/12-xproc-irc
   [6] http://www.w3.org/2006/10/12-xproc-minutes.html#action01
   [7] http://www.w3.org/2006/10/12-xproc-minutes.html#action01
   [8] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
   [9] http://dev.w3.org/cvsweb/2002/scribe/

    Minutes formatted by David Booth's scribe.perl[8] version 1.127 (CVS
    $Date: 2006/10/19 19:10:26 $

Received on Thursday, 19 October 2006 19:12:53 UTC