See also: IRC log
No regrets given.
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
... 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.
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: 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.
Norm: I think we need to consider which steps need to have names.
Henry: In section 2.1.1, do we
want to endorse the idea of default names, and if so, what gets
... 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]
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
... 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.