Re: Conditionals

Norm,

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>.

Say:

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

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

Alex

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):
http://www.orbeon.com/blog/

Received on Thursday, 16 March 2006 03:16:15 UTC