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

XProc Minutes 4 May 2006

From: Norman Walsh <Norman.Walsh@Sun.COM>
Date: Thu, 04 May 2006 12:33:29 -0400
To: public-xml-processing-model-wg@w3.org
Message-ID: <87psitvjfq.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2006/05/04-minutes.html


                                   - DRAFT -

                            XML Processing Model WG

Meeting 19, 4 May 2006


   See also: IRC log[3]


           Alessandro, Andrew, Henry, Michael, Norman, Paul, Richard, Rui,
           Alex, Murray

           Erik, Mohamed




     * Topics
         1. Accept this agenda?
         2. Accept minutes from the previous teleconference?
         3. Next meeting: 11 May telcon
         4. Face-to-face meeting
         5. Open action items
         6. Issue 3113: Does the pipeline engine act as a resource manager?
         7. Issue 3118: Should an implementation of the language be allowed
            to perform caching?
         8. Issue 3114: Are explicit dependencies required?
         9. Face-to-face meeting
     * Summary of Action Items


  Accept this agenda?

   -> http://www.w3.org/XML/XProc/2006/05/04-agenda.html


  Accept minutes from the previous teleconference?

   -> http://www.w3.org/XML/XProc/2006/04/27-minutes.html


  Next meeting: 11 May telcon

   Any regrets?

   Andrew is on vacation 11, 18 May

   Michael is away for 11, 18, 25 May

   Paul is away 11 May

   Henry is away 18 May

  Face-to-face meeting

   Registration: http://www.w3.org/2002/09/wbs/38398/XProcFTF2/[6]

   Local arrangements: http://www.w3.org/XML/XProc/2006/08/02-04-f2f.html[7]

   That's the beginnings of a local arrangements page, more details to follow

  Open action items

   A-18-01 is continued

   A-17-02 is in progress

   A-13-01 is continued, new ETA 15 June 2006

  Issue 3113: Does the pipeline engine act as a resource manager?


   Richard: I posted a couple of messages today, but looking at the example
   the email was talking about: XSLT importing a document produce somewhere
   ... This is a conventional temporary file problem
   ... Simply store things in files with generated names and then convey that
   name elsewhere.
   ... There are other examples, such as XIncluding things.
   ... You can simply transform the documents to refer to the generated file
   ... As a concrete proposal for the temporary file system; I suggest a
   component that takes a document as input, stores it somewhere, and returns
   the URI that it used.

   Alex: Do we have to do anything about this?

   Norm: I don't think consensus is moving towards support for this proposal

   HT: We'll need to spec quite carefully our story about pipeline
   parameters, variables, and their relationship to component and step
   ... We've been postponing that for some time. But to make the workarounds
   work most gracefully, that mechanism is going to have to be there.

   Proposal: No, the pipeline engine is not required to act as a resource


   Norm asks HT to expand on his pipeline/parameter variable story

   HT: Consider that I want to do something like this: take the output of
   Richards write input to temp file component and mediate between that and a
   component that will substitute the value into a document.
   ... I have a general purpose component that has two parameters, an XPath
   and a string. Wherever the XPath matches, it replaces what it finds with
   the string.
   ... The obvious thing to do is set the value of attributes or the text
   content of elements.
   ... Now I can get very close to doing the XInclude example if only I can
   get the result of Richards temporary component into a variable so that I
   can get it into a parameter.
   ... That's appealing to some fairly natural concepts of pipeline variables
   and ways of using pipeline variables to supply component parameters

   Alex: I wanted to second what Henry said. This is an important use case
   for lots of piplines I've built. I need to be able to bind to variables in
   a uniform way and be able to point into documents and update them.
   ... Deleting whole subtrees is an example.
   ... Renaming elements and attributes, namespaces, etc.

   Norm: I think it's important to make sure that we get the framework right
   to support all the kinds of components that we need.

   <scribe> ACTION A-19-01: Norm to create an issue for this [recorded in

   <scribe> ACTION A-19-02: Alex to send mail describing his ideas about
   variables [recorded in

   Richard: I wanted to mention a relationship between variable mechanisms
   and one of the issues that came up with the resource manager issue.
   ... If some component writes something to a temporary file, it's important
   that a component consuming it not try to read it before it's done.
   ... Using a variable to communicate the location of the temporary files
   gives you a mechanism for managing that.
   ... If a component can't start before the variable is set, then the
   process is managed by that variable.
   ... You might use variables for other kinds of synchronization as well if
   we did that.

   Norm: From the end of this discussion last week, how do we identify the
   inputs and outputs. By naming the endpoints or the things that flow
   through the pipe.
   ... From the list, I think consensus is moving towards identifying the end

   HT: Having worked for a while with the alternative, I think this is the
   right thing to do but we need to live with it for a while.
   ... It's not as immediately obvious to see what a graceful surface syntax
   is going to be.

   Alex: Internally, this is the right model. I'm just not convinced that
   there aren't cases where there are implicit connections to happen.
   ... But I'm willing to push that off to the future.

   HT: Absolutely.
   ... You don't want to see any of the low-level stuff at the authoring

   Richard: Abbreviation still leaves the question of what to do for the
   low-level syntax.
   ... Recall that there are two ways to do this: by having names on each
   input/output or by naming the steps and having standard names for the
   inputs/outputs on each component

   Alex: We can work on the shortcuts after we have a full syntax.

   Richard: I think you're basically right. There's an obvious back-door into
   a resource manager if you give all the inputs/outputs names that are URIs.

   Norm expresses some concern about readability of a naming scheme that
   relies on knowledge of the underlying component input/output names.

   <ht> Unabbreviated abstract syntax consists of:

           (Set of String)inputPorts,
           (Set of String)outputPorts,
           (Set of String)parameters)

 - ---------------

 Pipeline((Set of Component)components,
          (Set of String)parameters,
          (Set of Step)steps,
          (Set of Pipes)pipes,

      (Set of Binding)arguments)



 OutputPort == Port such that port is in |step|.component.outputPorts
 InputPort == Port such that port is in |step|.component.inputPorts

 Binding == ExplicitBind((String)name,(String)value) |
            BindByRef((String)name,(String)parameter) where parameter
              is in surrounding pipeline.parameters

 Invoke a pipeline with input?, output? and (Set of ExplicitBinding).

   Extracted by scribe from 2006May/0012.html[11]

   HT: Definition of a component in some implementation independent way

   HT: A step is a binding to a component

   HT: A pipe is a connection from an orgin to a destination
   ... In order to specify a pipe, you need to know the name of the step and
   the name of the port for each connection
   ... Note that ports have constant names and all that need to have ad hoc
   names are steps
   ... All components should have universal standard names for their primary
   input and primary output

   Norm: I think I hear consensus that we're going to take a stab at this by
   naming the endpoints that are bolted together.

   <richard> I gave an XML syntax for this way of expressing it in

  Issue 3118: Should an implementation of the language be allowed to perform


   <Alessandro> Absolutely

   Norm: I propose that in light of our decision about the "functionality" of
   components, this is purely a quality-of-implementation issue


  Issue 3114: Are explicit dependencies required?


   Norm: I don't think we have enough information to answer this yet.

   Richard: I think there's a simple synch. mechansim: have a component that
   waits until it has received a whole document.
   ... Then you use that component as input.
   ... Suppose you wanted to stop an XSLT component from running until some
   document had been generated. Then you could not give it its stylesheet
   until that document was ready.
   ... You could do that by passing the stylesheet through some component
   that waits until another document is fully written.

   Murray: How is it going to do that? By checking that it exists and is

   Richard: I imagine that this is a special purpose component that reads the
   ... The mechanism for sync. can probably be achieved by components in the

   Alex: In some sense I agree that having input dependencies is a great way
   to do this. But that may be confusing to users.
   ... But if we do synch. components then we have to deal with deadlock and
   other non-trivial issues.

   Murray: It occurs to me that if we had a p:depends element that named an
   input and an output then we could describe the dependency
   ... In addition to resolving the dependencies, it would provide an
   opportunity to rename things.

  Face-to-face meeting

   Murray: There's updated information on the page provided. In the comments
   section of the registration, please indicate how you planned to arrive and
   how you'd hope to travel.
   ... I'll send suggestions for how to get from the airport to here.
   ... This is a four-seasons resort area, so book rooms early.


Summary of Action Items

   [NEW] ACTION A-19-01: Alex to send mail describing his ideas about
   variables [recorded in
   [NEW] ACTION A-19-02: Norm to create an issue for this [recorded in
   [End of minutes]


   [1] http://www.w3.org/
   [2] http://www.w3.org/XML/XProc/2006/05/04-agenda.html
   [3] http://www.w3.org/2006/05/04-xproc-irc
   [6] http://www.w3.org/2002/09/wbs/38398/XProcFTF2/
   [7] http://www.w3.org/XML/XProc/2006/08/02-04-f2f.html
   [9] http://www.w3.org/2006/05/04-xproc-minutes.html#action01
   [10] http://www.w3.org/2006/05/04-xproc-minutes.html#action02
   [15] http://www.w3.org/2006/05/04-xproc-minutes.html#action02
   [16] http://www.w3.org/2006/05/04-xproc-minutes.html#action01
   [17] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
   [18] http://dev.w3.org/cvsweb/2002/scribe/

    Minutes formatted by David Booth's scribe.perl[17] version 1.127 (CVS
    $Date: 2006/05/04 16:32:08 $

Received on Thursday, 4 May 2006 16:33:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:39 UTC