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

Re: Conditionals

From: Alessandro Vernet <avernet@orbeon.com>
Date: Wed, 15 Mar 2006 19:16:09 -0800
Message-ID: <4828ceec0603151916p5f48012eg1ae89cf37cd51fd0@mail.gmail.com>
To: public-xml-processing-model-wg@w3.org


What does $status refer to in the pipeline? Would that be a parameter
of the pipeline? One way of looking at tests evaluated at runtime is
the following: we will want to have tests that run on infosets
manipulated in the pipeline. So as we have an attribute on <p:input>
to reference a named infoset ("use" in your example), we can use the
same attribute on the <p:choose>. Then it would be quite natural to
use XPath to perform the actual test. So the expression in the <p:when
test="..."> would be an XPath expression evaluated in the context of
the infoset referenced on <p:choose>.


    <p:choose use="some-document-label">
        <p:when test="/status = 'draft'">

        <p:when test="/status = 'final'">


On 3/15/06, Norman Walsh <Norman.Walsh@sun.com> wrote:
> With inputs, outputs, and sub-pipelines out of the way, we come,
> somewhat indirectly, to conditionals. Despite all the complex drawings
> that we had on the board at the f2f, I think a conditional (at least
> one where the condition can be evaluated before execution of the
> pipeline begins) is fairly simple conceptually.
> Let's say we have a p:choose element. If we say that all the branches
> of the choice must have the same number of inputs and outputs then
> I think it's not too difficult to understand:
>   <p:choose>
>     <p:input name="schemas" label="s"/>
>     <p:input name="document" label="d"/>
>     <p:output label="ok"/>
>     <p:when test="$status = 'draft'">
>       <p:step name="devnull">
>         <p:input use="s"/>
>       </p:step>
>       <p:step name="identity">
>         <p:input name="document" use="d"/>
>         <p:output/>
>       </p:step>
>     </p:when>
>     <p:when test="$status = 'final'">
>       <p:call-pipeline name="expandandvalidate">
>         <p:input name="schemas" use="s"/>
>         <p:input name="document" use="d"/>
>         <p:output/>
>       </p:call-pipeline>
>     </p:when>
>     <p:otherwise>
>       <p:error>
>         <p:input use="s"/>
>         <p:input use="d"/>
>         <p:output/>
>         <p:message>What the heck did you set $status to exactly?</p:message>
>       </p:error>
>     </p:otherwise>
>   </p:choose>
> Like a sub-pipeline, a p:choose defines its inputs and outputs, that
> way it fits into the pipeline irrespective of what branch is selected.
> I haven't got my head around how to define tests that are evaluated at
> runtime based on currently active inputs and outputs.
>                                         Be seeing you,
>                                           norm
> --
> Norman.Walsh@Sun.COM / XML Standards Architect / Sun Microsystems, Inc.
> NOTICE: This email message is for the sole use of the intended
> recipient(s) and may contain confidential and privileged information.
> Any unauthorized review, use, disclosure or distribution is prohibited.
> If you are not the intended recipient, please contact the sender by
> reply email and destroy all copies of the original message.

Blog (XML, Web apps, Open Source):
Received on Thursday, 16 March 2006 03:16:15 UTC

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