W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > April 2006

Minutes for XProc WG telcon of 13 Apr 2006

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:21:47 GMT