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

Re: A "processing model" proposal

From: Erik Bruchez <ebruchez@orbeon.com>
Date: Fri, 17 Feb 2006 20:48:11 +0100
Message-ID: <43F6287B.8080102@orbeon.com>
To: public-xml-processing-model-wg@w3.org

Norman Walsh wrote:
 > / Erik Bruchez <ebruchez@orbeon.com> was heard to say:
 > | Richard & all,
 > | Here is how you do this with XPL [1]:
 > | <p:pipeline version = "1.0"
 > |             xmlns:p="http://www.orbeon.com/oxf/pipeline"
 > |             xmlns:xpl="http://www.orbeon.com/oxf/xpl/standard"
 > |             xmlns:my="http://www.example.org/xpl/my-components">
 > |     <p:input name="document-1"/>
 > |     <p:input name="document-2"/>
 > |     <p:output name="result" infosetref="diff"/>
 >
 > What's the significance of naming the result "result"? (I don't see it
 > referenced anywhere else in the pipeline.)

This is the name through which the result infoset can be accessed by
the caller of the pipeline. Input infosets are passed by name, and
output infosets are accessible by name as well. The choice of the name
"result" here is completely arbitrary.

In the case above I chose to return the resulting infoset as a
pipeline output. You could also choose to write it on disk from within
the pipeline. With XPL you use a "component" to do that, the "File
serializer", although you could certainly imagine a syntax using a
(writable) URL, but this is not in the XPL spec at the moment.

 > |     <p:processor name="xpl:xslt">
 > |         <p:input name="data" infosetref="#document-1"/>
 > |         <p:input name="stylesheet" infosetref="strip-ids.xsl"/>
 > |         <p:output name="data" infoset="stripped-1"/>
 > |     </p:processor>
 > |     <p:processor name="xpl:xslt">
 > |         <p:input name="data" infosetref="#document-2"/>
 > |         <p:input name="stylesheet" infosetref="strip-ids.xsl"/>
 > |         <p:output name="data" infoset="stripped-2"/>
 > |     </p:processor>
 > |     <p:processor name="my:diff">
 > |         <p:input name="doc1" infosetref="#stripped-1"/>
 > |         <p:input name="doc2" infosetref="#stripped-2"/>
 > |         <p:output name="diff" infoset="diff"/>
 > |     </p:processor>
 > | </p:pipeline>
 > | The syntax is straightforward, but feel free to ask questions. Note
 > | that the stylesheets are *not* "parameters", as there is no reason to
 > | make a difference between the stylesheet and the main input of the
 > | transformation: both are XML documents.
 >
 > Indeed. What about the case where I want to pass the parameter
 > "chunk-on-sections" with the value "1" to the XSLT processor?

XPL does not support parameters natively, so you don't do this
directly. However in the rare case we need this, we use a little
trick: the ability to embed an infoset directly in the <p:input>
element, and inheritance of parameters in XSLT. The result becomes:

   <p:processor name="xpl:xslt">
     <p:input name="data" infosetref="#document-1"/>
     <p:input name="stylesheet">
       <xsl:stylesheet version="1.0">
         <!-- This is the stylesheet to pass parameters to -->
         <xsl:import href="strip-ids.xsl"/>
         <!-- Here we assign a value to the "start" parameter -->
         <xsl:param name="chunk-on-sections" select="1"/>
       </xsl:stylesheet>
     </p:input>
     <p:output name="data" id="..."/>
   </p:processor>

We think that this mechanism is acceptable based on our personal use
cases which do not massively require passing parameters to
stylesheets, but we understand that people may think this is not
sufficient. Note that with this, you can pass any XML type you want as
parameters: you are not limited to strings or numbers.

In many cases, a stylesheet may require more configuration
information, in which case we have defined a URI scheme called "input"
which allows writing things, from withing an XSLT stylesheet, like:

   doc('input:my-input')

This allows the stylesheet to read a processor input called
"my-input", declared as:

   <p:input name="my-input" infosetref="#something"/>

This has also contributed to limiting the number of uses cases where
parameters are required. The same technique can be used from an
XInclude processor:

   <xi:include href="input:my-input"/>

-Erik
Received on Friday, 17 February 2006 19:52:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:21:47 GMT