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