- From: Norman Walsh <Norman.Walsh@Sun.COM>
- Date: Thu, 21 Sep 2006 12:39:31 -0400
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <87ac4tkwcc.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2006/09/21-minutes.html
- DRAFT -
XML Processing Model WG
Meeting 36, 21 Sep 2006
Agenda[1]
Attendees
Present
Norm, Alex, Michael, Mohamed, Henry, Erik, Richard
Regrets
Paul, Andrew, Murray
Chair
Norm
Scribe
Norm
Minutes
[Norm struggles, fails to get an internet connection. ]
Topic: Accept this agenda?
-> http://www.w3.org/XML/XProc/2006/09/21-agenda.html
Accepted.
Topic: Accept minutes from the previous meeting?
-> http://www.w3.org/XML/XProc/2006/09/14-minutes.html
Accepted.
Topic: Next meeting: telcon 28 Sep 2006
No regrets given; Norm, Henry give regrets for 5 Oct 2006.
Topic: Review of open action items
1. A-35-01: Norm to fix Figure 2 in XProc language specification
Completed.
2. A-35-02: Norm to request permission to publish FPWD
Completed.
3. A-13-01: MSM to draft a complete table in Requirements document
Continued.
We have a FPWD, http://www.w3.org/XML/XProc/docs/WD-xproc-20060928/
Topic: Technical discussion
Norm: I drew the analogy with compiler optimizations. The "single
graph" looks to me a little like loop unrolling or procedure inlining.
While that's reasonable, I don't think any modern languages are
described that way.
Alex: But they aren't data flow languages.
Henry: I think the major reason for the non-single graph approach is
that I want to be able to pick up chunks of the pipeline document and
paste them and not worry about name conflicts. The encapsulation that
you get from the nested graph model seems to be a crucial gaurantor of
the validity of doing that.
... We need to say something about the validity of a "global variable
reference" and I think what Norm originally proposed goes the right
way.
Alex: I don't think we have the cut-and-paste semantics that you think we do.
Henry: I think we do.
Alex: We don't have scoping of step names right now.
Michael: What troubles me about Henry's cut-and-paste argument is that
I don't think that the ability to omit declarations actually supports
that use case. You might not get an error, but who knows what that
points to.
... There was an example of references outside a container and I don't
think there's anything in there that would provide a gaurantee. It was
just like global variables.
... Even explicit declarations don't help since they have references
outside as well.
Henry: I think Michael is right. I can imagine that we might approach
this in the following way: the basic fact of the matter is that
components inside subpipelines can only refernece steps that are their
siblings or ports on the container by which they are immediately
contained. Then there are two directions one could go: one is to say
"that's it"; if you want to refer out then you have to put a
declaration on the margin that bridges that. If we wanted to adopt any
kind of shorthand or automatic bridging, then there ought to be two
modes of operation: one in which you bridge silently and another in
which you don't.
... What I want to avoid is something that has no bridges becoming
invalid by moving it.
Richard: Looking back at the messages, sometimes people seem to be
talking about how to view the pipeline, other times people are talking
about visibility of names from inside a component to outside. These
aren't necessarily the same thing.
... I think we should assume that any kind of naming scopes that we
have in pipelines will all match up or be reducable to a single issue
about how the diagrams are nested. In particular, when you draw the
diagrams, all the names have gone.
Norm: Fair point.
Henry: There's still a question in the drawings. In the nested model,
the boxes have substance. Sometimes the lines cross box boundaries and
sometimes they don't.
Henry: In the nested model, no pipe crosses a box boundary. In the
flat graph model, the dotted line that reconstructs the original has
lines that cross it.
Richard: In Michael's graphic, there are no lines crossing anywhere.
Alex: To some extent you have that problem. There are still inputs that
come to you inside things that are arbitrarily deep.
Norm: I had in mind an inner-to-outer build model that would remove
all the crossing lines.
Richard: If that's the case, then we have something more rigid than
what Henry said. Pipes are only connected to boxes inside that box,
not even to any ancestor boxes.
... You could, in the syntax, allow you to refer to things all over
the place, but this would be equivalent of adding ports where
necessary. You can do it the opposite way around, allowing connections
only to ports of siblings. But then you could still have a flat graph.
Norm: That's why it feels like compiler optimization.
Michael: I agree that it feels like loop unrolling. One of the
concerns that I have about the nested model is that if you want the
kind of reference to ancestors that we used to have, then I can
understand that much better in the flat view than I can in the nested
view.
... If we want strong encapsulation, then we should learn from
languages that have it. All of the bindings of arguments to parameters
happens outside not inside the lexical scope of the thingy. The fact
that the examples feel "ok" when they violate that modularity means
that the flat graph seems like a much closer reflection of my user
model looking at those examples.
... The nested model would be much closer if, as in the case of
function declarations, the function wasn't declared inline. Each of
the graphs in the nested drawing would be a contiguous bit without
interruptions.
Richard: One way to look at it is that in the flat view, the box is
like a closure. It has it's parameters, but it also closes over any
external ports that it references. You can turn a closure into a more
normal view by adding parameters.
Norm: That sounds right to me.
Richard: One thing that we have now that we didn't have before is the idea
that we have explicit semantics. We can either say that the convenient
syntax is a shortcut for something or we can simply say that it has the
more verbose semantics.
Michael: Please, let's not.
Norm: Indeed, let's not.
Richard: From the point of view of what the language actually is, the
question is whether we allow a short form. If we allow a short form,
then we can do it either way. If we don't allow a short form, then
doing it the short way seems pointless.
Alex: Part of this thread started with the uncomfortableness of the
former section 4.1.3. My main thrust is that I don't want the ability
to do this latice-based model to go away. I don't care if we describe
it that way.
... My problem is with describing this in terms of fabricating
declarations that don't exist.
... I'd rather talk about this stuff in terms of what happens to
inputs. We need to make sure that inputs don't get provided to
components when you're on the wrong branch of a choose.
... But let's not talk about fabricated declarations.
Norm outlines his view again.
Alex: I'd be a lot more happy if the syntax was legal.
Richard: You're talking about things being delivered to the wrong
branches. We don't have a pull model. All the things outside the box
will happen, even if the things inside the box don't read them.
... The strange thing that can happen is that some component outside
the box can produce output that will never be consumed. But it's still
going to produce the output.
Norm describes his idea of the semantics of choose, where it has all
the inputs that it might need before it starts.
Alex: You have talked about reading inputs, but I have a model where
inputs are delivered asynchronously.
... In the flow model, all of those inputs are in fact connected, it's
just a question of which ones have water in them.
... You have to build a "valve" in the lattice.
More discussion about implementation models.
Alex: I'd much prefer the closure story to the notion of fabricating
declarations.
Richard: The closure story and the fabricating declarations story are
essentially equivalent. If you have something like a closure in our
pipeline language, you could implement it as a box with extra inputs.
Michael: In our FPWD, we have a definition that I think feels right: a
pipeline is a directed, acyclic graph of components.
Norm attempts a description
Michael: So "the pipeline" has no knowledge of the "make FO" component.
Henry: Although there are two levels of nesting in the element
structure. There's only one level of nesting in the box. Whereas
viewport has a single subpipeline, the choose has several but they are
not more nested.
Michael: Attempt to say as a shorthand that it's a directed, acyclic
graph of components is wrong. The story you're telling is a lot more
complicated than that.
Henry: Complex components like choose are black boxes, I don't think
we every said that the subpipelines are black boxes.
Richard: The when branches of a choose are not themselves black boxes?
Henry: No, they're directly part of the choose.
Norm: Alas, we're out of time. Hopefully we can come to closure on
this next week.
Topic: Any other business?
None.
Adjourned.
[1] http://www.w3.org/XML/XProc/2006/09/21-agenda.html
Received on Thursday, 21 September 2006 16:39:45 UTC