W3C home > Mailing lists > Public > public-xml-processing-model-comments@w3.org > October 2009

Re: Another take on versioning

From: Jeni Tennison <jeni@jenitennison.com>
Date: Mon, 12 Oct 2009 11:00:48 +0100
Message-Id: <E610D874-079A-4AC0-9915-4EDEAB2EA08C@jenitennison.com>
To: public-xml-processing-model-comments@w3.org

On 12 Oct 2009, at 10:06, <Toman_Vojtech@emc.com>  
<Toman_Vojtech@emc.com> wrote:

>>> But the dependency between the two steps must still be preserved.
>>> Simply
>>> replacing the p:pipe binding would break the dependency graph.
>> I don't really understand why this is important, given that
>> if there's
>> no data passing between them then there is no dependency
>> between them.
>> But I will defer to the implementers.
> Even if no data is flowing between the steps, you want to be sure they
> are evaluated in the right order. Consider this example:
> <p:v2-step name="v2"/>
> <p:v1-step>
>  <p:input port="source">
>    <p:pipe step="v2" port="result"/>
>  </p:input>
> </p:v1-step>
> In a V1 processor, this pipeline should fail because the processor  
> does
> not know how to perform p:v2-step. As a consequence, the p:v1-step  
> step
> is never invoked (because it depends on the result of p:v2-step).
> Hovever, if you remove the dependency between p:v1-step and p:v2-step
> (by replacing p:pipe with p:empty), the V1 processor is at liberty to
> evaluate the two steps in arbitrary order. This means that p:v1-step  
> can
> be evaluated *before* p:v2-step, which typically you don't want (you
> will be likely to get errors or really unexpected results when running
> the pipeline). For instance, p:v1-step might store nonsense documents
> somewhere, or update some records in a db too early, ...

OK, so we need wording that says that if a pipeline contains a step  
that it doesn't recognise (eg the v2 step in the above) then it must  
not run any steps in the pipeline. Right? But that's a separate issue.

I thought you were going to give an illustration which showed:

   * one of the XProc 1.0 steps that has side effects (ie p:store) has  
an extra output port added to it in v2.0

   * that step is used in a v2.0 pipeline along with a step that is  
sensitive to side-effects (eg p:directory-list)

   * the pipeline is set up such that the *only* dependency between  
p:directory-list and p:store is through the extra output port

and persuade me to care that the person running the v2.0 pipeline with  
a v1.0 processor didn't get the same output that they would have if  
they'd have been running it in a v2.0 processor. Then I would have  
argued that anyone designing a v2.0 pipeline that contains a  
meaningful dependency based purely on a new output port, but wants the  
pipeline to be runnable in v1.0 processors, is going to have to do  
some extra work introducing those dependencies through other means.  
And that's OK.

Jeni Tennison
Received on Monday, 12 October 2009 10:01:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:28:27 UTC