- From: Norman Walsh <Norman.Walsh@Sun.COM>
- Date: Thu, 13 Apr 2006 14:39:51 -0400
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <87ek01nwug.fsf@nwalsh.com>
See also: http://www.w3.org/XML/XProc/2006/04/13-minutes.html
W3C[1]
- DRAFT -
XML Processing Model WG
13 Apr 2006
Agenda[2]
See also: IRC log[3]
Attendees
Present
Norm, Rui, Mohamed, Alessandro, Michael, Andrew, Alex
Regrets
Henry, Paul, Richard
Chair
Norm
Scribe
Norm
Contents
* Topics
1. Accept this agenda?
2. Accept minutes from the previous teleconference?
3. Next meeting: 20 Apr telcon
4. Issue 3096: Are components side-effect free?
5. Issue 3113: Does the pipeline act as a resource manager?
6. Issue 3114: Are explicit dependencies required
7. Any other business?
* Summary of Action Items
----------------------------------------------------------------------
Accept this agenda?
-> http://www.w3.org/XML/XProc/2006/04/13-agenda.html
Accepted.
Accept minutes from the previous teleconference?
-> http://www.w3.org/XML/XProc/2006/04/06-minutes.html
Accepted.
Next meeting: 20 Apr telcon
Any regrets?
Rui gives regrets for 20 and 27 April
Issue 3096: Are components side-effect free?
-> 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
Issue 3113: Does the pipeline act as a resource manager?
-> 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
Issue 3114: Are explicit dependencies required
-> 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
Any other business?
None
Summary of Action Items
[End of minutes]
----------------------------------------------------------------------
[1] http://www.w3.org/
[2] http://www.w3.org/XML/XProc/2006/04/13-agenda.html
[3] http://www.w3.org/2006/04/13-xproc-irc
[9] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
Be seeing you,
norm
--
Norman.Walsh@Sun.COM / XML Standards Architect / Sun Microsystems, Inc.
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
Received on Thursday, 13 April 2006 18:39:59 UTC