- From: Norman Walsh <Norman.Walsh@Sun.COM>
- Date: Thu, 19 Oct 2006 15:12:15 -0400
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <8764eg6rxs.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2006/10/12-minutes.html
W3C[1]
- DRAFT -
XML Processing Model WG
Meeting 39, 12 Oct 2006
Agenda[2]
See also: IRC log[3]
Attendees
Present
Paul, Rui, Alessandro, Norm, Mohamed, Murray, Henry, Richard,
Andrew, Michael
Regrets
None
Chair
Norm
Scribe
Norm
Contents
* 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
Accepted.
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.
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[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
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?
None.
Adjourned.
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[7]]
**
[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
log[9])
$Date: 2006/10/19 19:10:26 $
Received on Thursday, 19 October 2006 19:12:53 UTC