See also: IRC log
-> http://www.w3.org/XML/XProc/2006/10/12-agenda.html
Accepted, with Murray's addition of order of processing per the GRDDL WG
-> http://www.w3.org/XML/XProc/2006/10/05-minutes.html
Accepted.
No regrets given.
Completion of table in requirements document; continued.
<scribe> New ETA: November, 2006
<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.
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.]
None.
Adjourned.