See also: IRC log
-> http://www.w3.org/XML/XProc/2006/04/13-agenda.html
Accepted.
-> http://www.w3.org/XML/XProc/2006/04/06-minutes.html
Accepted.
Any regrets?
Rui gives regrets for 20 and 27 April
-> http://www.w3.org/Bugs/Public/show_bug.cgi?id=3096
Alex: Couldn't we take the XSLT approach and not say?
Norm: XSLT assumes that they are side effect free, can we assume the same?
Alex: If you want a side-effect,
pass the stuff through the pipeline.
... Something that goes around the back and passes a note can't
be prevented
<MoZ> side effect free is intimately related to management of resources
Alex: If parameter are a separate
thing, then you could imagine a step that sets
parameters.
... I'm not sure we know enough about the whole structure to
know how to resolve this
... Is it sufficient to say for now that we don't want to
encourage side effects?
MSM: I wonder if it would do the
trick to say, if there are side-effects their order and number
of times they occur is undefined.
... If you know the order of side effects is going to be ok,
then you know something that this spec does not and this
implementation is not obligated to tell you
... "It's your problem"
Alessandro: What is the
definition of a side-effect in this discussion?
... Given the same input documents, a transformation might
produce different outputs
... And I see a lot of components that would be useful, to
fetch things from a database or web service for example, where
it would be hard to gaurantee no side effects
Norm: I want it to be the case that if you pass the same inputs to a component, you will get the same result. Or that an engine is free to return the same result.
MSM: In that formulation, I have a lot more sympathy
<MoZ> imagine the information of the time and date
Norm expresses again his desire to be able to cache results
<MoZ> hey that's my sample :)
<MoZ> Norm, XSLT is a functionnal language
<MSM> [MSM thinks the discussion is not sufficiently clear in distinguishing the cases where (a) side-effect-free ness is required and (b) it is allowed and (c) it's not allowed (whatever that might mean)]
<MoZ> Norm, +1 for default is side effect free
Alessandro: What is the value of saying components are side-effect free? Unspoken benefit is related to caching, which I support. But it looks like the type of side-effect free language we are thinking about would only have an implication on caching on running the same steps multipe times in the same pipeline
<MoZ> Alessandro, not just caching but also intrepreting the structure
Alessandro: I don't see that case
as happening very often
... Is this really the case we're talking about?
<MoZ> good example is cocoon expire parameter
Alessandro: The case I see more often is that you run the same pipeline multiple times and you want to cache results across multiple executions.
Norm: Good point.
Norm wonders if we should just move on?
<MoZ> +1 for later resolution
-> http://www.w3.org/Bugs/Public/show_bug.cgi?id=3113
Alex: The MT pipeline, and my
pipeline, both do this
... It's a nice thing
... I'm not sure this is something we have to define
Norm describes a case with a serialized URI that's later xsl:imported in a stylesheet
<MoZ> this case is for me a good example of optimization of a pipeline : if the user don't optimize he do want you say and for the pipeline they are different
<MoZ> if he want to optimize he uses label
<MoZ> in that case we could even use event
Alex: I think this should have to
be explicit.
... We could make it possible to bind these implicit inputs in
an explicit way.
More discussion :-/
Norm: I'm concerned about the complexity of designing a mechanism for making these things explicit and the overhead of deploying that mechanism everytime it's needed
<MoZ> we could imagine if it is not explicit we could just make simple deduction, if information is explicit we could make stronger deduction
Alex: This is a binding from URIs to infosets. Is this something that always happens or do you have to say something in the pipeline to make this explicit
Norm: I don't hear us driving towards consensus on this one
Alex: We should put that use case
in the issue
... We have to decide soon what sort of access you have to
inputs/outputs other than through pipes
-> http://www.w3.org/Bugs/Public/show_bug.cgi?id=3114
Norm attempts to describe the situation
Norm: (badly)
<MoZ> Norm, not so bad
Alex: For streaming to work, you need to know all the dependencies
<MoZ> if graph is not unique we should issue a warning
Alex: We need to be able to construct the graph and if the resource manager plays games with that graph, we need to know
Norm: Maybe this issue depends on our resolution of 3113
<MoZ> i think the are related 3113 and 3114 but in both way
Norm: If you have a mechanism, as Alex suggested, to make the resource manager explicit, theyn this issue is subsumed
Alex: They're related, not
necessarily subsumed.
... I'd suggest that we start here.
Norm isn't sure how to start here
Norm: If you don't care about side effects and you don't have a resource manager, then when do you ever need dependencies other than inputs and outputs?
Alex: depending on a URI is a kind of input/output that isn't directly related to flow through the pipeline
Norm: So you could have inputs/outputs and a facility for describing auxilliary inputs, resources that are produced/consumed, identified by URI
Alex: Yes
Norm wonders how to deal with dynamic resources in this model
Norm: How are inputs distinct from resources consumed or outputs and resources produced?
Alex: I'm not sure there's a lot
of difference, but it comes into play in streaming
... The inputs/outputs in the MT pipeline were important for
determining thread boundaries
... I should be able to deduce optimizations from a good flow
graph
None