XML Processing Model WG

Meeting 104, 20 Mar 2008


See also: IRC log


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


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

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 ports.
... but that doesn't work, because _steps_ don't have to refer in lexical order.
... 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 ports.
... 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 interoperable.
... 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 p:step-available(p:for-each)

Norm: I think it should be yes

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

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 try-catch?

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

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 http://www.w3.org/2008/03/20-xproc-minutes.html#action01]

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

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]

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]
[NEW] ACTION: Henry to consider the issue of names and the media type in general and come back with a proposal. [recorded in http://www.w3.org/2008/03/20-xproc-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2008/03/27 16:20:12 $