W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > September 2006

XProc Minutes 21 Sep 2006

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:21:48 GMT