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

RE: The resource manager use case

From: <vojtech.toman@emc.com>
Date: Thu, 26 Apr 2012 09:59:32 -0400
To: <public-xml-processing-model-wg@w3.org>
Message-ID: <F3C7EBECE80AC346BE4D1C5A9BB4A41F2ED14E4FE0@MX11A.corp.emc.com>
How would the XProc processor see the "soft" dependency between the p:xinclude step and the ext:get-weather... step in your example? I think we will have to either provide more information on the p:xinclude (ala depends-on), or go for the "scoped" resource manager construct.

An aside regarding stylesheets, queries, schemas etc. - I think we have a slight inconsistency in the spec. In p:validate-with-xml-schema, you can pass a sequence of schemas to the "schema" input port, and these schemas will take precedence when processing locating schemas and processing xs:import. Unfortunately, we don't have the same in p:xslt or p:xquery. But the resource manager should solve it.

And just a final thought: what about the situation when you have a step with two input ports, but you want to use a different resource manager for each port? It is clearly a corner case, but I could imagine a situation (for example, with the p:xslt step) in which "foo.xml" should be interpreted differently in the stylesheet and in the data.


Vojtech

--
Vojtech Toman
Consultant Software Engineer
EMC | Information Intelligence Group
vojtech.toman@emc.com
http://developer.emc.com/xmltech


> -----Original Message-----
> From: Norman Walsh [mailto:ndw@nwalsh.com]
> Sent: Thursday, April 26, 2012 3:37 PM
> To: public-xml-processing-model-wg@w3.org
> Subject: The resource manager use case
> 
> The canonical resource manager use case, to my mind, is the XInclude
> case. Consider this slightly contrived example.
> 
> input.xml:
> 
>   <doc>Today's weather is
>     <xi:include href="todays-weather.xml"/>
>   </doc>
> 
> pipeline.xpl:
> 
>   <p:pipeline>
>      ...
> 
>      <ext:get-weather-based-on-params-or-locale-or-whatever
>           base-uri="todays-weather.xml"/>
> 
>      <p:xinclude>
>        <p:input port="source">
>          <p:document href="input.xml"/>
>        </p:input>
>      </p:xinclude>
> 
>      ...
>   </p:pipeline>
> 
> The idea is that the get-weather... step produces a document with the
> appropriate base URI and then when XInclude goes off to get that
> document, the pipeline provides the document generated by some other
> step in the pipeline.
> 
> It's possible, for any given case, to imagine ways to rewrite the
> pipeline, but the general case remains: processing some documents will
> appeal to URIs and it would be useful to be able to generate the
> documents that should satisfy those URIs in other steps in the pipeline
> (consider synthesized stylesheets and schemas, for example).
> 
>                                         Be seeing you,
>                                           norm
> 
> --
> Norman Walsh
> Lead Engineer
> MarkLogic Corporation
> Phone: +1 413 624 6676
> www.marklogic.com
Received on Thursday, 26 April 2012 14:00:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 14:00:26 GMT