Hi,
Le vendredi 28 janvier 2005 � 12:01 +0100, Eric van der Vlist a �crit :
I am not completely happy with the pipe I have proposed the other day:
> <p:config>
>
> <p:param name="data" type="input">
> <p:param name="target" type="input">
> <p:param name="data" type="output">
>
> <p:choose href="#target">
> <p:when test="target='xml'"> xml serializer </p:when>
> <p:when test="target='html'"> html serializer </p:when>
> </p:choose>
>
> <p:processor name="oxf:identity">
> <p:input name="data" href="#data"/>
> <p:output name="data" ref="data"/>
> </p:processor>
>
> </p:config>
It's kind of mixing to different paradigms: the target input that
triggers the choose and the data output that pulls the output when no
branches of the choose are matched.
Since we've more or less discarded the target approach, I think that it
would be better if we could rely of the pull approach to choose the
branch as well.
That means, being able to define a pipe (let's call it "multi.xpl") from
which we could either pull data for further processing or pull a XML,
HTML or text serialisation.
In other words, a pipe that we could use as in the following
page-flow.xml:
<page id="default" path-info="/tests/default" view="multi.xpl"/>
<page id="xml" path-info="/tests/xml" model="xml.xpl"/>
<page id="html" path-info="/tests/html" model="html.xpl"/>
<page id="text" path-info="/tests/text" model="text.xpl"/>
with
text.xpl:
<p:config xmlns:p="http://www.orbeon.com/oxf/pipeline";
xmlns:oxf="http://www.orbeon.com/oxf/processors";>
<p:processor name="oxf:pipeline">
<p:input name="config" href="multi.xpl"/>
<p:output name="text" id="text"/>
</p:processor>
<p:processor name="oxf:null-serializer">
<p:input name="data" href="#text"/>
</p:processor>
</p:config>
xml.xpl:
<p:config xmlns:p="http://www.orbeon.com/oxf/pipeline";
xmlns:oxf="http://www.orbeon.com/oxf/processors";>
<p:processor name="oxf:pipeline">
<p:input name="config" href="multi.xpl"/>
<p:output name="xml" id="xml"/>
</p:processor>
<p:processor name="oxf:null-serializer">
<p:input name="data" href="#xml"/>
</p:processor>
</p:config>
and html.xpl:
<p:config xmlns:p="http://www.orbeon.com/oxf/pipeline";
xmlns:oxf="http://www.orbeon.com/oxf/processors";>
<p:processor name="oxf:pipeline">
<p:input name="config" href="multi.xpl"/>
<p:output name="html" id="html"/>
</p:processor>
<p:processor name="oxf:null-serializer">
<p:input name="data" href="#html"/>
</p:processor>
</p:config>
As you see, I am using the same pipe and in the first case
(/tests/default) I am pulling a document through its "data" output to
apply the epilogue while in the three other cases I am pulling the
"text", "xml" and "html" outputs into a null serializer to provoke a
text, xml or html serialization.
This requires that these serializations are not done automatically and
that would be very easy if there wasn't this rule to call the init
method of each processor without output.
In fact, that's doable right now, but not as straightforward as one
could hope:
multi.xpl:
<p:config xmlns:p="http://www.orbeon.com/oxf/pipeline";
xmlns:oxf="http://www.orbeon.com/oxf/processors";>
<p:param name="data" type="output"/>
<p:param name="xml" type="output"/>
<p:param name="html" type="output"/>
<p:param name="text" type="output"/>
<p:processor name="oxf:identity">
<p:input name="data" href="index.xhtml"/>
<p:output name="data" id="document"/>
</p:processor>
<p:processor name="oxf:pipeline">
<p:input name="doc1" href="#document"/>
<p:input name="config">
<p:config>
<p:param name="doc1" type="input"/>
<p:param name="pull1" type="output"/>
<p:processor name="oxf:xml-serializer">
<p:input name="config">
<config/>
</p:input>
<p:input name="data" href="#doc1"/>
</p:processor>
<p:processor name="oxf:identity">
<p:input name="data">
<empty/>
</p:input>
<p:output name="data" ref="pull1"/>
</p:processor>
</p:config>
</p:input>
<p:output name="pull1" ref="xml"/>
</p:processor>
<p:processor name="oxf:pipeline">
<p:input name="doc2" href="#document"/>
<p:input name="config">
<p:config>
<p:param name="doc2" type="input"/>
<p:param name="pull2" type="output"/>
<p:processor name="oxf:html-serializer">
<p:input name="config">
<config/>
</p:input>
<p:input name="data" href="#doc2"/>
</p:processor>
<p:processor name="oxf:identity">
<p:input name="data">
<empty/>
</p:input>
<p:output name="data" ref="pull2"/>
</p:processor>
</p:config>
</p:input>
<p:output name="pull2" ref="html"/>
</p:processor>
<p:processor name="oxf:pipeline">
<p:input name="doc3" href="#document"/>
<p:input name="config">
<p:config>
<p:param name="doc3" type="input"/>
<p:param name="pull3" type="output"/>
<p:processor name="oxf:text-serializer">
<p:input name="config">
<config/>
</p:input>
<p:input name="data"
href="#doc3#xpointer(/xhtml:html/xhtml:body)"
xmlns:xhtml="http://www.w3.org/1999/xhtml"/>
</p:processor>
<p:processor name="oxf:identity">
<p:input name="data">
<empty/>
</p:input>
<p:output name="data" ref="pull3"/>
</p:processor>
</p:config>
</p:input>
<p:output name="pull3" ref="text"/>
</p:processor>
<p:processor name="oxf:identity">
<p:input name="data" href="#document"/>
<p:output name="data" ref="data"/>
</p:processor>
</p:config>
Why is that so verbose to implement that?
My new take on the issue is that instead of this rule to call the init
method of processors without connected outputs, we could on the contrary
make sure that each processor as at least an output that can be used to
pull actions.
If you go back to real pipelines, if you want that something happens,
you need to provide an output to your pipe, otherwise they won't be any
circulation of fluid. If you take the metaphor or an electric circuit,
you need to provide a difference of potential to have a current.
In the case of XPL, I am beginning to think that the issue we have is
due to the fact that are ignoring that simple fact and wanting to insure
that fluids will flow without output or that there will be a current
without difference of potential.
We could remove this "not natural" rule and add "action" outputs to the
serializers and multi.xpl would become as simple as:
<p:config xmlns:p="http://www.orbeon.com/oxf/pipeline";
xmlns:oxf="http://www.orbeon.com/oxf/processors";>
<p:param name="data" type="output"/>
<p:param name="xml" type="output"/>
<p:param name="html" type="output"/>
<p:param name="text" type="output"/>
<p:processor name="oxf:identity">
<p:input name="data" href="index.xhtml"/>
<p:output name="data" id="document"/>
</p:processor>
<p:processor name="oxf:xml-serializer">
<p:input name="config">
<config/>
</p:input>
<p:input name="data" href="#document"/>
<p:output name="action" href="#xml"/>
</p:processor>
<p:processor name="oxf:html-serializer">
<p:input name="config">
<config/>
</p:input>
<p:input name="data" href="#document"/>
<p:output name="action" href="#html"/>
</p:processor>
<p:processor name="oxf:text-serializer">
<p:input name="config">
<config/>
</p:input>
<p:input name="data" href="#document"/>
<p:output name="action" href="#text"/>
</p:processor>
<p:processor name="oxf:identity">
<p:input name="data" href="#document"/>
<p:output name="data" ref="data"/>
</p:processor>
</p:config>
In fact, the only processor without output would be oxf:null-serializer
that would add as the ground in an electric circuit or a sink for a
pipeline.
Would that make sense?
Eric
--
Read me on XML.com.
http://www.xml.com/pub/au/74
------------------------------------------------------------------------
Eric van der Vlist http://xmlfr.org http://dyomedea.com
(ISO) RELAX NG ISBN:0-596-00421-4 http://oreilly.com/catalog/relax
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
orbeon-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/orbeon-user
