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

URIs as inputs and outputs

From: Jeni Tennison <jeni@jenitennison.com>
Date: Wed, 05 Apr 2006 20:50:32 +0100
Message-ID: <44341F88.702@jenitennison.com>
To: public-xml-processing-model-wg@w3.org


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" />

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?


Jeni Tennison
Received on Wednesday, 5 April 2006 19:50:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:39 UTC