OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tamie message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [tamie] Exit question


Title: Exit question
Chuck: inline.
-J


From: Morris, Chuck E (IT) [mailto:chuck.morris@ngc.com]
Sent: Thursday, January 29, 2009 12:45 PM
To: tamie@lists.oasis-open.org
Subject: [tamie] Exit question

Suppose you have a scriplet that generates an XML effect.  Maybe it adds two values from events that it catches and puts them into a total elemet, like this:

<scriplet>
  <total>
    <var name="total1">
      <catch>
         <match condition="content/order[@customer='1']/@total"/>
      </catch>
    </var>
    <if condition="$total1 lt 0">
       <exit/>
    </if>
    <var name="total2">
      <catch>
         <match condition="content/order[@customer='2']/@total"/>
      </catch>
    </var>
    <if condition="$total2 lt 0">
       <exit/>
    </if>
    <eval expr="$total1 + $total2"/>
  </total>
</scriplet>

Everything is fine as long as both totals are greater than 0.  But if either of the exit conditions are met, what is the effect of the scriplet?

I see three options:

1)  The effect is anything that was produced up to when the exit was encountered.  In this case, that would be an empty total element.

2)  The effect is nothing at all.  

<JD> Interesting problem. I think it all hinges on what are the rules to generate effects:

(a) if the rules are:

rule 1: if a scriplet does not generate a well-formed xml (or exits before doing so) then its effect is nil (or "empty").

rule 2: a scriplet can only generate a well-formed xml effect. Meaning  if scriplet A has the tag <total>, and calls scriplet B that has the closing tag </total>, then that is still not correct as Scriplet B violates this rule, and by ripple effect Scriplet A also violates the rule (as the effect of B would be nil).

Your solution (2) is the thing to do according to these rules. But if the rule is:

rule 3: a scriplet has no understanding of the xml semantics of its effect: it just outputs anything that is not etsm-namespaced.

Then I guess there is yet another option: just produce an incomplete <total> fragment, that would fail validation.

3)  We allow the exit instruction to be a container for other instructions.  When an exit is encountered, its effect becomes the effect of the scriplet.  For example,

<if condition="$total2 lt 0">
  <exit>
    <error>Total must be greater than or equal to zero</error>
  </exit>
</if>

At this point, I like option 3.  

<JD>  I am also in favor of the <exit> being able to produce an effect, otherwise there is no hope of getting any meaningful effect out of an "exiting" scriplet, since a brutal exit is almost sure to break any xml effect that was being prepared, as in your example. Now, after thinking about it, I think it is OK to say that the exit effect becomes THE effect of the scriplet.

Indeed, that does not prevent the developer to combine regular effect and a convenient usage of <exit>:

Consider the first scriplet that would not work according to your suggestion (because the total effect would "loose" the container tag <myapp:results>):

<scriplet>
  < myapp:results
        <if condition="$total1 lt  10 ">
       <exit>  <myapp:estimate> very cheap ! </myapp:estimate> </exit> 
    </if> 
   <if condition="$total1 lt  100 ">

       <exit>  <myapp:estimate> still cheap ! </myapp:estimate></exit>
    </if>
  
    <if condition="$total1 lt  500 ">
       <exit>  <myapp:estimate> moderate! </myapp:estimate></exit>
    </if>
  
    <if condition="$total1 lt  1000 ">
       <exit>  <myapp:estimate> a bit pricey </myapp:estimate></exit>
    </if> 

  < / myapp:results>
</scriplet>
  

But the following  rewriting would work fine. Note that the "exit" must NOT bubble up, for this to work, whic is the default bubbling option (it would not work if we called S2 as: <call scriplet="S2" bubblexit="true" > )

 <scriplet name="S1"> 
    <param name="total"/>
    <myapp:results
    <call scriplet="S2"><withparam name="total" expr="$total"/></call>
    </myapp:results>
<scriplet>
 
<scriplet   name=" S ">   
    <param name="total"/> 
     <if condition="$total1 lt  10 ">
       <exit>  <myapp:estimate> very cheap ! </myapp:estimate> </exit> 
    </if> 
   <if condition="$total1 lt  100 ">

       <exit>  <myapp:estimate> still cheap ! </myapp:estimate></exit>
    </if>
  
    <if condition="$total1 lt  500 ">
       <exit>  <myapp:estimate> moderate! </myapp:estimate></exit>
    </if>
  
    <if condition="$total1 lt  1000 ">
       <exit>  <myapp:estimate> a bit pricey </myapp:estimate></exit>
    </if> 

 </scriplet> 
 
So bottomline: I'd be in favor of your option (3) and I think also of above rules (1) and (2) with <exit> accommodation.
 
-jacques

- Chuck



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]