W3C home > Mailing lists > Public > www-voice@w3.org > April to June 2006

Re: SCXML : Event Generation and Dynamic Creation of Statechart

From: Sheth Raxit <raxit@phonologies.com>
Date: Mon, 17 Apr 2006 11:53:44 +0530
Message-ID: <44433470.4060909@phonologies.com>
To: www-voice@w3.org, James.Barnett@Aspect.com, bond@research.att.com

Greg, Jim,

Thanks for your  reply,

Greg:
 >"ECharts supports dynamic creation/destruction of submachine instances 
*within a state*."

Yes,

Raxit(previous post):
 >I think (but not much sure )that <invoke> can be modeled as , Dynamic
 >Creation of new State (with new State-Id) and call to appropriate
 >services, and as  actuall call is madeup from new state, with new
 >stateid, What Gilman has suggested the concepts of Event would now apply

in above line,
Dynamic Creation of new State (within current state-hierarchy from which 
<invoke> called) (with new state-id) and...

I mean to say NOT  a New-State at TOP LEVEL, But creation of newstate at 
current level (i.e. Either Parallel or SubState) from where <invoke> 
called (and which one would semantically appropriate if this possible  
parallel/substate?  because <invoke> can not be direct child of <scxml> ),

Would it  be Semantically equivalent of Event-related stuff (suggested 
by Gilman),  ?



Thanks,
Raxit Sheth

Gregory W. Bond wrote:

> Raxit
>
> I agree with Jim that dynamic state creation is a bad idea. I would 
> also like to clarify that ECharts does not support this concept. 
> Rather, ECharts supports dynamic creation/destruction of submachine 
> instances *within a state*. This approach ensures the number of states 
> is fixed and therefore is amenable to analysis. This approach also has 
> the advantage that the dynamic aspects of the program are part of the 
> state machine and can therefore be analyzed as part of the state machine.
>
> Greg
>
> On Apr 13, 2006, at 9:57 AM, Barnett, James wrote:
>
>> Raxit,
>>   Dynamic creation of states is something that we have consciously ruled
>> out for SCXML.  The basic idea of state machines is that they have a
>> fixed set of states. Even push-down automata, which are more powerful
>> than finite state machines, have a fixed set of states, plus a dynamic
>> stack.
>>
>> One strong advantage of having a fixed set of states is that machines
>> are statically analyzable - by looking at chains of transitions, you can
>> determine whether there is a path from any given state to any other
>> state.
>>
>> We therefore do not want any constructs in SCXML that involve the
>> dynamic creation of states.  There is a way of handling multiple
>> <invoke> at the platform layer that does not have this problem, and we
>> will post a message on this topic soon.
>>
>> - Jim
>>
>>
>> -----Original Message-----
>> From: Sheth Raxit [mailto:raxit@phonologies.com]
>> Sent: Monday, April 10, 2006 2:05 AM
>> To: www-voice@w3.org; Barnett, James; bond@research.att.com;
>> Alfred.S.Gilman@IEEE.org
>> Subject: SCXML : Event Generation and Dynamic Creation of Statechart
>>
>> Respected  James,Greg,Gilman and other VBVG Members,
>>
>> With reference to previous posts, One of the point is to Generate Event
>> and related stuff while processing <invoke>, I think that this is
>> somewhat  like (or can be modeled as)  what  Greg has mentioned ( in
>> this post
>> http://lists.w3.org/Archives/Public/www-voice/2006JanMar/0040.html ),
>> issue ,"Dynamic Creation of Statecharts".
>>
>> I think (but not much sure )that <invoke> can be modeled as , Dynamic
>> Creation of new State (with new State-Id) and call to appropriate
>> services, and as  actuall call is madeup from new state, with new
>> stateid, What Gilman has suggested the concepts of Event would now apply
>>
>> to this New-State, and this new-state now would do all the event
>> handling and related stuff.
>>
>> when SCXML Engine hits <invoke>
>> 1. Dynamically Create new state, (with unique State Id)
>> 2. Make appropriate stuff to call Service,
>> 3. Call the Service,
>> 4. Do Event Handling for the Events arrived from services,
>>
>>
>> Would it  be Semantically equivalent of Event-related stuff (suggested
>> by Gilman),  ?
>>
>> Any thought on this issue ?
>>


-- 

Raxit Sheth
Systems Software Engineer
Raxit@Phonologies.com

***********************
Please note our new Address.
***********************
Phonologies (India) Private Limited
17/18 Metro House, Colaba Causeway,
Mumbai 400001. INDIA.
Ph:+91-22-22029732 / 36   Fax:+91-22-22029728

Info@Phonologies.COM
http://www.phonologies.com

****The information in this email is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this email by
anyone else is unauthorized. If you are not the intended recipient, any
disclosure, copying, distribution or any action taken or omitted to be taken
in reliance on it, is prohibited and may be unlawful****
Received on Monday, 17 April 2006 06:15:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 30 October 2006 12:49:02 GMT