- From: Jeni Tennison <jeni@jenitennison.com>
- Date: Wed, 05 Apr 2006 20:50:32 +0100
- To: public-xml-processing-model-wg@w3.org
Hi,
I've been toying with an idea and I'd like to see whether others think
it's worth pursuing.
The crux is that instead of passing *documents* between steps, we pass
*URIs*. The pipeline processor acts as a resource manager/entity
resolver. Whenever a component wants to read a document, it requests it,
using the URI, from the pipeline processor. Whenever a component wants
to write a document, it registers it with a particular URI with the
pipeline processor (and that URI can be supplied to the component when
the step is defined).
For example, in something like:
<p:step use="xslt2.0">
<p:input name="source" href="a.xml" />
<p:input name="stylesheet" href="b.xsl" />
<p:output name="result" href="c.xml" />
</p:step>
means that the XSLT processor is passed the URI 'a.xml' associated with
the name 'source', 'b.xml' associated with the name 'stylesheet' and
'c.xml' associated with the name 'result'. The XSLT processor requests
the documents associated with 'a.xml' and 'b.xsl' from the pipeline
processor. When it's done, the XSLT processor tells the pipeline
processor to associate the resulting document with the URI 'c.xml'.
If a URI is requested and that URI is explicitly specified as an output
of a step, then the returned document must be the same as that generated
by the component. It's an error if creating that document entails
requesting that URI (i.e. you can't have circular pipelines).
Within a single execution, a pipeline processor will always deliver the
same document for a given URI: it's stable for the duration of the
pipeline. Also, only one document can be registered with a particular
URI during a single execution, so you don't get documents overwritten.
Using URIs rather than documents unifies the treatment of inputs that
are passed explicitly to the component and inputs that it uses
internally (e.g. through the doc() function in XSLT or XQuery or
referenced within the document being processed), which means that those
inputs can also be the results of other steps in the pipeline.
Having URIs for all the intermediate documents means that it's easy to
look at the intermediate results, which is handy for debugging.
I have a feeling that there's a glaring problem with this that I'm
missing. Perhaps it rests too heavily on a backward-chaining assumption.
Any thoughts?
Cheers,
Jeni
--
Jeni Tennison
http://www.jenitennison.com
Received on Wednesday, 5 April 2006 19:50:41 UTC