XML Processing Model WG

12 Oct 2006


See also: IRC log


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



Date: 12 Oct 2006

<scribe> Meeting: 39

<scribe> Scribe: Norm

<scribe> ScribeNick: Norm

Accept this agenda?

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

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

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

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 syntax.
... 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 scope.
... 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 ports.

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.

<alexmilowski> hi

<alexmilowski> (sorry I'm late... I'm traveling in MN)

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

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

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

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

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?



MSM, I don't see how a computed parameter differs from any other input

If you want to start your components before all the inputs are available in the optimistic hope that it won't matter, fine.

That's an optimization, not a conceptual change.

If you can't optimize components that have computed parameters as easily, or completely, as ones that don't: c'est la vie.

Summary of Action Items

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

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2006/10/12 16:58:13 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.127  of Date: 2005/08/16 15:12:03  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/step naming/scope of step names/
Succeeded: s/step order/scope of step names/
Found Scribe: Norm
Inferring ScribeNick: Norm
Found ScribeNick: Norm
Default Present: PGrosso, Alessandro_Vernet, [IPcaller], Norm, Rui, MoZ, Murray_Maloney, Ht, richard, AndrewF, MSM, +1.218.444.aaaa
Present: Paul Rui Alessandro Norm Mohamed Murray Henry Richard Andrew Michael
Agenda: http://www.w3.org/XML/XProc/2006/10/12-agenda.html
Found Date: 12 Oct 2006
Guessing minutes URL: http://www.w3.org/2006/10/12-xproc-minutes.html
People with action items: norm

[End of scribe.perl diagnostic output]