Re: Antwort: RE: SCXML specification

Michael,

I am sorry to be slow in replying to you, but it took us a while to
schedule time to discuss your email.  I would like to respond to your
point 4).  This idea (allowing 'cond' to be an element as well as an
attribute) has been raised by people within the group, and we think it
is worth considering.  However it is unlikely that we will do this until
after we complete the SCXML 1.0 specification.  We think that this is a
complicated proposal that would require careful discussion, and we are
reluctant to undertake anything new since it is taking us a long time to
complete SCXML  1.0 as it is.  In the interim, we suggest that you use a
special profile to allow the functionality that you want. 

 

Best,

-          Jim

 

 

 

>> Michael wrote

4) Yes, i appreciate the concept of profile and i can workaround this 

issue - but its a workaround. The extension of actions semantics is 

possible on a per element base, conditions not. Again an example from my


functor world:

 

This would do the job

 

<scxml name="Test" initial="A" version="1.0">

 

   <state id="A">

 

      <onentry>

         <perform type="JavaScript" source="app.alert('enter A')"/>

      </onentry>

 

      <transition event="a" cond="computeCondition()" target="B">

         <perform type="JavaScript" source="app.alert('to B')"/>

         <perform type="JavaScript">

            <source>

        /* some complex source that should not mess with xml attribute 

delimiters.../*

        var a = "foo'bar";

            </source>

         </perform>

      </transition>

 

   </state>

 

   ...

 

</scxml>

 

<perform> is my generic, XML based statement. I can switch, on each 

instance from such types like "JavaScript", "Debug", "Python",...

 

The condition on the other hand is tied to a single language and forced
in 

an xml attribute syntax. I have no way to get this in a more complex 

element. This would be heaven:

 

<scxml name="Test" initial="A" version="1.0">

 

   <state id="A">

 

      <onentry>

         <perform type="JavaScript" source="app.alert('enter A')"/>

      </onentry>

 

      <transition event="a" target="B">

         <guard>

            <perform type="JavaScript" source="computeCondition()"/>

         </guard>

         <ontrigger>

            <perform type="JavaScript" source="app.alert('to B')"/>

            <perform type="JavaScript">

               <source>

        /* some complex source that should not mess with xml attribute 

delimiters.../*

        var a = "foo'bar";

               </source>

            </perform>

            </ontrigger>

      </transition>

 

   </state>

 

   ...

 

</scxml>

 

Simply putting executable action always in a container of its own (as in


onentry) would bring the extensibility that i need (and gives room for 

further extension on the transition later on). The roles of the actions 

within transition is kind of underspecified.

 

 


					
-------------------------------------------------------------------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.