Re: Auxiliary documents

Norman Walsh wrote:
> / Jeni Tennison <jeni@jenitennison.com> was heard to say:
> Certainly in the implementation that I envision, the pipeline engine
> will act as the entity resolver/URI resolver for the components.
> 
> I'd like to make that part of the specification, but I'm not sure it's
> something that all implementations can reasonably be expected to
> support.

Presumably you have some implementation in mind that wouldn't be able to 
act as a resource manager?

The reason I'm in favour of mandating that the pipeline engine acts as a 
resource manager is to avoid the possibility of side effects. To avoid 
side effects, we need to ensure that the same document is returned every 
time it's requested (during a single invocation of a pipeline). We also 
need to make sure that we don't get the situation where two components 
write to the same URI.

I want to avoid side effects so that it's possible to have 
parallel-processing distributed pipeline engines.

> | We also need to decide whether/how to support the situation where the auxiliary
> | document is itself the result of a pipeline, or whether we explicitly exclude
> | this. We need to say what happens when a "Saved" document is "Loaded" or
> | requested as an auxiliary document, particularly if we want to allow parallel
> | processing strategies.
> 
> Indeed. I'm not sure what we can say about the parallel execution
> case. Perhaps we need to allow pipelines to indicate that one
> component depends on another even though it doesn't appear to.

Yes, I think we probably do need that facility for the cases where the 
URIs of the outputs of a step aren't made explicit in the pipeline document.

But I think that if the URI of an output document is specified in the 
pipeline document then the user shouldn't have to indicate what order 
the steps need to be run in. In your example:

> <p:pipeline>
>   <p:input name="doc1"/>
>   <p:output name="doc2"/>
> 
>   <p:xslt>
>     <p:input name="document" label="doc1"/>
>     <p:input name="stylesheet" href="mystyle.xsl"/>
>     <p:output href="otherdoc.xml"/>
>   </p:xslt>
> 
>   <p:xinclude>
>     <p:input href="mydoc.xml"/>
>     <p:output name="document" label="doc2"/>
>   </p:xinclude>
> </p:pipeline>

when the XInclude step requests otherdoc.xml, the pipeline engine should 
be able to recognise that otherdoc.xml is a result of the XSLT step, and 
therefore run the XSLT to produce it.

Cheers,

Jeni
-- 
Jeni Tennison
http://www.jenitennison.com

Received on Wednesday, 12 April 2006 13:40:56 UTC