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

XProc Minutes 20 Mar 2008

From: Norman Walsh <ndw@nwalsh.com>
Date: Thu, 20 Mar 2008 12:03:18 -0400
To: public-xml-processing-model-wg@w3.org
Message-ID: <m2skyll6wp.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2008/03/20-minutes


                                   - DRAFT -

                            XML Processing Model WG

Meeting 104, 20 Mar 2008


   See also: IRC log[3]


           Norm, Henry, Paul, Richard, Alex, Mohamed, Murray

           Michael, Rui




     * Topics
         1. Accept this agenda?
         2. Accept minutes from the previous meeting?
         3. Next meeting: telcon 27 March 2008?
         4. Editor's alternate draft
         5. Comment #129, fallback for V.next compound steps
         6. #128/#126 revised ontology and step names
         7. Issue #53, parallelism
         8. Any other business?
     * Summary of Action Items


  Accept this agenda?

   -> http://www.w3.org/XML/XProc/2008/03/20-agenda


  Accept minutes from the previous meeting?

   -> http://www.w3.org/XML/XProc/2008/03/06-minutes


  Next meeting: telcon 27 March 2008?

   No regrets given.

  Editor's alternate draft

   -> http://www.w3.org/XML/XProc/docs/langspec.html

   Norm attempts to summarize the alternate draft.

   Henry: I think the new draft is a definite step forward.

   Alex: I agree too.

   Norm: I also added multi-step container

   Mohamed: The p:variable looks like a step too.
   ... Between steps we can have p:variable, which means we can have a change
   in step dependencies

   Henry: I don't think it changes step dependencies.

   Norm: Mohamed is right. Because p:variable can contain p:pipe.

   Henry: We could say, you can't do that.
   ... Or we could say that the context document must be empty.

   Mohamed: I think we can just say that p:variable is a step that exposes

   Henry: I think that makes the scoping rules impossible to write.
   ... There seem to be two ways to think of this. One as a limited kind of
   step and one like XSLT variables.
   ... So we could say that variables can only depend on lexically preceding
   ... but that doesn't work, because _steps_ don't have to refer in lexical
   ... Very little is lost, and we still get almost all the intended benefit
   if we push variables back into the prologue.
   ... We can leave them where they are, but they can't see sibling output
   ... This puts option and variable in complementary distributions.
   ... So you can have options or variables and perhaps only in pipeline
   declarations can have both.

   Basically, variables need more work.

   Mohamed: General opinion is that we've improved things, the alternate
   draft is definitely an improvement.

   Proposed: We'll take the current altnerate draft as the starting point for
   further development.


   Norm: We need to resolve variable first, so let's skip the second item on
   the technical agenda for now.

  Comment #129, fallback for V.next compound steps

   Norm: As it stands, I think, an implementor can provide a new compound
   step, but that pipeline just won't run in any other processor.

   Henry: I'm against p:fallback. In XSLT, p:fallback is restricted to
   instruction elements, the interior of templates. You cannot extend XSLT by
   defining a new kind of template element. You can't add my:supertemplate.
   There's no way to do that.
   ... For my money, the compound steps and multi-containers are like that
   for us. There's just no way to do it that's backward compatible or
   ... The chances that you can define a workaround that are so small, that
   adding a whole bunch of mechanism to the language, just in case someone
   can is all out of proportion.
   ... I'd like to go less far, I don't think we need to say anything at all
   about extension compound steps.

   Norm: I'm sorry that we're forever closing the door, but I tend to agree
   with Henry.

   Mohamed: We say that we're going to provide a file that contains the
   atomic step declarations. Can we also provide a small signature for
   compound steps?

   Norm: I don't think so; you need to know the inputs and outputs in order
   to build the graph.

   Henry concurs.

   Henry: There is one more question: what is the answer to

   Norm: I think it should be yes

   Henry: I agree.
   ... What about step-available for a pipeline that you've declared in

   Norm: I think that should be 'true' too.

   Proposed: We won't make any attempt to provide interoperable extension
   compound steps.

   Mohamed: Can't we try to make something possible from inside a when or a

   Norm: I don't think so, because you wouldn't know the bindings if it
   occured, for example, as the last step in a p:when subpipeline.

   Returning to the proposal: accepted.

  #128/#126 revised ontology and step names

   Norm: I think we need to consider which steps need to have names.

   <ht> http://www.w3.org/XML/XProc/docs/langspec.html#step-names[7]

   Henry: In section 2.1.1, do we want to endorse the idea of default names,
   and if so, what gets a name.
   ... At the moment, all steps and all containers get names. I think that's
   fine as long as the odd containers aren't steps.

   Norm: They used to need names, but they don't anymore.

   Henry: Right, the rule that applies now is the Dan Connolloy rule that
   important things ought to have names.

   Norm: The XProc Media Type comes into play here.

   <scribe> ACTION: Henry to consider the issue of names and the media type
   in general and come back with a proposal. [recorded in

  Issue #53, parallelism

   Norm: Nokolai asks if we're content with a story that means a pipeline
   might succeed in parallel and fail in serial.

   Henry: Yes, and we should provide an example.
   ... Branch 1 computes a stylesheet and branch 2 uses it.
   ... You should plumb them together.

   Norm: You can use a variable or option to achieve serial execution.

   Richard: One thing that wouldn't work would be to have an output that went
   from the first to the second but not consumed by the step.

   Scribe isn't sure he got this right.

   Henry: I don't want to have to dive into the details of the fine structure
   of step invocation.

   Richard: I think there are some things that ensure it, but it isn't simply
   connecting a pipe.

   Henry: I don't think there's anything you can do that will work for every
   plausible implementation strategy.

   Some discussion of an implementation that prefetches all URLs, in order to
   acheive the XSLT gaurantee.

   Murray: If you prefetch, you might get yesterday's answer.

   Henry: That was my goal; to make sure that nothing the pipe did could
   change what I got.

   Murray: We can say that when things are moving through the pipeline,
   they're in your control. Anytime you put them on the filesystem, you can
   get arbitrary results.

   Richard: Provided I can constrain the outer environment, I can be sure the
   C runtime won't mess up the files. Are we going to say the same thing
   about pipelines.

   Henry: No, I don't want to attempt to provide gaurantees about execution

   Richard: I'm not disagreeing, I'm just exploring the possibilities.
   ... There are some things that do gaurantee an order. A step inside a when
   can't start until the conditional has been evaluated.
   ... The steps in a catch can't be started until after the try has failed.

   Henry: I note that this is a counter example to my original claim, that
   the following is a perfectly acceptable implementation strategy: put all
   the steps in a separate thread and start them all.
   ... In fact, this proposal has always been wrong.
   ... Consider the following case: my XSLT step implementation says the
   minute you get started, look at the pipeline XSLT stylesheet cache and use
   it or start building an entry in the cache.
   ... That's perfectly reasonable. That's sufficient to say that nothing you
   do that doesn't involve a choose or a try catch can prevent yesterday's
   stylesheet from being used.

   Richard: Let's consider another example: we've got p:store and it writes
   to a URI and produces a result that contains that URI.
   ... Do we expect that there will be any gaurantee that the result will not
   appear on the output port until the document has been written.

   Norm: We probably want to fix p:store

   <scribe> ACTION: Editor to write a chapter or appendix on parallelism.
   [recorded in http://www.w3.org/2008/03/20-xproc-minutes.html#action02[9]]

   Henry: I thought something about non-side-effects might usefully go in
   p:pipeinfo, but I'm not sure anymore.

  Any other business?


Summary of Action Items

   [NEW] ACTION: Editor to write a chapter or appendix on parallelism.
   [recorded in http://www.w3.org/2008/03/20-xproc-minutes.html#action02[10]]
   [NEW] ACTION: Henry to consider the issue of names and the media type in
   general and come back with a proposal. [recorded in
   [End of minutes]


   [1] http://www.w3.org/
   [2] http://www.w3.org/XML/XProc/2008/03/20-agenda
   [3] http://www.w3.org/2008/03/20-xproc-irc
   [7] http://www.w3.org/XML/XProc/docs/langspec.html#step-names
   [8] http://www.w3.org/2008/03/20-xproc-minutes.html#action01
   [9] http://www.w3.org/2008/03/20-xproc-minutes.html#action02
   [10] http://www.w3.org/2008/03/20-xproc-minutes.html#action02
   [11] http://www.w3.org/2008/03/20-xproc-minutes.html#action01
   [12] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
   [13] http://dev.w3.org/cvsweb/2002/scribe/

    Minutes formatted by David Booth's scribe.perl[12] version 1.133 (CVS
    $Date: 2008/03/20 16:02:36 $

Received on Thursday, 20 March 2008 16:03:55 UTC

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