Return-Path: 
 <commons-user-return-17027-apmail-jakarta-commons-user-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-commons-user-archive@www.apache.org
Received: (qmail 7540 invoked from network); 21 Jul 2006 12:06:53 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 21 Jul 2006 12:06:53 -0000
Received: (qmail 76441 invoked by uid 500); 21 Jul 2006 12:06:45 -0000
Delivered-To: apmail-jakarta-commons-user-archive@jakarta.apache.org
Received: (qmail 76393 invoked by uid 500); 21 Jul 2006 12:06:45 -0000
Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:commons-user-unsubscribe@jakarta.apache.org>
List-Help: <mailto:commons-user-help@jakarta.apache.org>
List-Post: <mailto:commons-user@jakarta.apache.org>
List-Id: "Jakarta Commons Users List" <commons-user.jakarta.apache.org>
Reply-To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Delivered-To: mailing list commons-user@jakarta.apache.org
Received: (qmail 76379 invoked by uid 99); 21 Jul 2006 12:06:45 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 21 Jul 2006 05:06:45 -0700
X-ASF-Spam-Status: No, hits=2.8 required=10.0
	tests=DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,DNS_FROM_RFC_WHOIS
X-Spam-Check-By: apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Received: from [206.190.38.123] (HELO web50903.mail.yahoo.com)
 (206.190.38.123)
    by apache.org (qpsmtpd/0.29) with SMTP; Fri, 21 Jul 2006 05:06:40 -0700
Received: (qmail 82903 invoked by uid 60001); 21 Jul 2006 12:06:19 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=v0Ya3O3he6GxI5Ful9ki7KgrlxShb/dEWZ1ZUSrz+PVRiSkjPKn6a12m6bZUl6mdeAIahwv2EesZRSNZ8y5hYuYZiCy50pmTfzxEfzf0tuK0G9rRs1hwMVGx/UL6QaoEMkzkZo1Pe3uGsAWndumO/YsfG/HvjLEFR1O/3Ls3GKk=
  ;
Message-ID: <20060721120619.82901.qmail@web50903.mail.yahoo.com>
Received: from [72.148.142.191] by web50903.mail.yahoo.com via HTTP;
 Fri, 21 Jul 2006 05:06:19 PDT
Date: Fri, 21 Jul 2006 05:06:19 -0700 (PDT)
From: Nestor Urquiza <nestoru@yahoo.com>
Subject: Re: [scxml] nested if statements
To: Jakarta Commons Users List <commons-user@jakarta.apache.org>
In-Reply-To: <ce1f2ea80607201928l7687c42dr9e12479382d3caff@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

Absolutely right ;-) I did not understand you well and
thanks for finding out my bug!
Best Regards,
Nestor

--- Rahul Akolkar <rahul.akolkar@gmail.com> wrote:

> On 7/20/06, Nestor Urquiza <nestoru@yahoo.com>
> wrote:
> > Hello Rahul ... could we reopen this issue? Seems
> like
> > the w3c working group is in its way to accept
> nested
> > <if>. Please could you read below the answer from
> them
> > as well as my reply about even the use of the
> <script>
> > tag?
> >
> <snip/>
> 
> I probably wasn't clear in my closing comment on
> SCXML-12 [1]. Nested
> <if> statements should be no trouble. What I meant
> by <elseif> and
> <else> being partitions, rather than containers, is
> that the following
> snippet (as well as the snippet you post below) is
> malformed:
> 
> <if cond="...">
>   <!-- if actions -->
>   <else>
>   <!-- else actions -->
>   </else>
> </if>
> 
> whereas it should be:
> 
> <if cond="...">
>   <!-- if actions -->
>   <else/>
>   <!-- else actions -->
> </if>
> 
> Further, the "if actions" or "else actions" may
> themselves contain
> other if statements, and this may recurse to any
> arbitrary levels of
> nesting.
> 
> 
> > I am currently with a lot of business rules to
> > evaluate and definetely when it comes to
> complexity a
> > good flow control/scripting mechanism is needed.
> <snap/>
> 
> Commons SCXML will not develop a scripting language.
> However, if there
> are expression languages that support scripting
> (neither EL nor JEXL's
> latest releases support that -- EL won't ever, JEXL
> has script support
> available in SVN trunk ATM so its next release
> should) they may be
> plugged in to provide such <script> support.
> However, that is unlikely
> to happen before a Commons SCXML 1.0 release (we're
> currently aiming
> for a 0.5 release).
> 
> Note that a refined datamodel with a well-defined
> event lifecycle can
> provide useful hooks for actions rather than
> resorting to ad-hoc
> scripting. Time will tell us what the SCXML
> datamodel ends up looking
> like.
> 
> -Rahul
> 
> [1] http://issues.apache.org/jira/browse/SCXML-12
> 
> 
> > That
> > is my goal right now ... to make scxml suitable
> for
> > modeling and configuring complex business
> processes
> > like the State Oriented Business Protocol I am
> > building for my Company.
> > Thanks!,
> > Nestor
> >
> > ***************************************
> > w3c thread:
> > ****************************************
> > Thanks a lot Barnett. Just for your information I
> am
> > using commons-scxml to manage a State Oriented
> > Business Protocol based on Harel Statecharts. As
> the
> > business rules grow the complexity needed grows as
> > well and without good flow control it is kind of
> > difficult to get efficient results.
> >
> > I was wondering if besides having nested
> conditions
> > wouldn't be wonderful to be able to use the
> <script>
> > element (http://www.w3.org/TR/scxml/#N107D9) using
> > ECMA inside or why not as commons-scxml has
> proposed
> > jexl or je as scripting languages. Do you think it
> > makes sense to use a <script> portion inside an
> > <onentry> just to setup final variables that could
> be
> > tested later on the <onentry> or <transiton>
> internal
> > FSM events?
> >
> > Thanks!,
> > Nestor
> >
> > --- "Barnett, James" <James.Barnett@aspect.com>
> wrote:
> >
> > > Nestor,
> > >   After a little discussion in the group, it
> turns
> > > out that we weren't
> > > very clear on this either.  However, we have
> > > provisionally decided to
> > > allow them since VoiceXML does.  We will clarify
> the
> > > issue in the next
> > > public draft.
> > >
> > > - Jim
> > >
> > > -----Original Message-----
> > > From: www-voice-request@w3.org
> > > [mailto:www-voice-request@w3.org] On
> > > Behalf Of Nestor Urquiza
> > > Sent: Friday, July 14, 2006 8:09 AM
> > > To: www-voice@w3.org
> > > Subject: [scxml] nested conditions
> > >
> > >
> > > Hello all,
> > > After reading http://www.w3.org/TR/scxml/#N109D0
> it
> > > is
> > > not clear to me if nested "<if>" are allowed.
> With
> > > an
> > > example is the code below supposed to be scxml
> > > valid?
> > > ...
> > > <n:if cond="status1 eq 'false'">
> > >    <!-- a first nested condition -->
> > >    <n:if cond="status2 eq 'true'  ">
> > >       <n:assign name="result" expr="'status1
> > > false'"/>
> > >    <n:else>
> > >       <n:assign name="result" expr="'statuses
> > > false'"/>
> > >    </n:else>
> > > <n:else>
> > >    <!-- another nested condition -->
> > >    <n:if cond="status2 eq 'true'  ">
> > >       <n:assign name="result" expr="'statuses
> > > true'"/>
> > >    <n:else>
> > >       <n:assign name="result" expr="'status2
> > > false'"/>
> > >    </n:else>
> > > </n:else>
> > > </n:if>
> > >
> > > Thanks,
> > > Nestor
> > **************************************
> > end w3c thread
> > ***************************************
> >
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-user-help@jakarta.apache.org
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org