- 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
W3C[1]
- DRAFT -
XML Processing Model WG
Meeting 104, 20 Mar 2008
Agenda[2]
See also: IRC log[3]
Attendees
Present
Norm, Henry, Paul, Richard, Alex, Mohamed, Murray
Regrets
Michael, Rui
Chair
Norm
Scribe
Norm
Contents
* 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
Accepted.
Accept minutes from the previous meeting?
-> http://www.w3.org/XML/XProc/2008/03/06-minutes
Accepted.
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.
Accepted.
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[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
http://www.w3.org/2008/03/20-xproc-minutes.html#action01[8]]
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[9]]
Henry: I thought something about non-side-effects might usefully go in
p:pipeinfo, but I'm not sure anymore.
Any other business?
None.
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
http://www.w3.org/2008/03/20-xproc-minutes.html#action01[11]]
[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
log[13])
$Date: 2008/03/20 16:02:36 $
Received on Thursday, 20 March 2008 16:03:55 UTC