Re: SCXML specifications

the almost simillar points  ( 1. Extension and 2. Conversion to 
SCXML)(with the specific example of CCXML)  are in previous post  
(*SCXML : CCXML Extension to SCXML Or CCXML to SCXML conversion ?)  
(http://lists.w3.org/Archives/Public/www-voice/2006JanMar/0034) 
<http://www.w3.org/2002/02/mid/43F2D6B5.9080903@phonologies.com;list=www-voice>

*The Technique 1 : Defining Custom Tags for SCXML Derived  implementation
*
in reference to that, some patterns of  Mapping of  ccxml tags and 
events  observed (and many other might have observed)
ex.

*|<dialogprepare>  --->  ||dialog.prepared,||error.dialog.notprepared
||<dialogstart>    --->  dialog.started,error.dialog.notstrted,dialog.exit
||<accept>         --->   connection.connected

etc...

and many other simillar tags, (mainly not referenced in SCXML 
'Datamodel' and 'Executable Content' section)

(And mainly, when ccxml execution engine / platform would execute the 
<tag> in following manner

1. tag.STARTED or (simillar) Event
2, tag.progressing (NOT in all tags)
3. tag.COMPLETE (execution of tag completed ---SUCCESSFUL in many cases)
4. tag.ERROR (Some error)


"Is this pattern (mapping ---Language specific syntax---language 
specific events) one of the key-aspects of SCXML Derived Language (CCXML 
is one of them) Specific Extension"  ?

For Creating a SCXML Derived new language  and Platform implementation

1. SCXML Datamodel
2. SCXML Executable content
3. Specification of Derived Platform describing   New Tag(s)----Event(s) 
Mapping


What's your opinion ?

Waiting for reply,


Many Thanks,


Regards
Raxit Sheth
|**

Barnett, James wrote:

>Jo,
> I have only a high-level idea of what you're trying to do, but can think of two ways it might fit into SCXML.  First off, we intended to allow implementations to extend the data model and executable content (this extensibility may not be made very clear in the current draft of the spec). So you could embed your descriptions in the datamodel, creating new data model primitives if necessary.  Roughly speaking, you can define your own tags to go inside <datamodel> and <onentry><onexit> etc.  Your implementation can then execute them as it sees fit (within the constraints of the overall SCXML semantics, which will be made precise in a future version of the spec.)
>
>The second technique you could look at is XSLT transformation.  You could define a higher-level  language containing all the information you want, then use an XSLT style sheet to convert that into SCXML plus, optionally, other  structures.  
>
>In the former case, your descriptive information ends up inside the SCXML state machine (and isn't really used at runtime).  In the second case, your higher-level language would contain both the state information and the descriptive information, and the XSLT would  convert the former into SCXML and the latter into an appropriate documentation format.
>
>- Jim
>
>
>-----Original Message-----
>From: www-voice-request@w3.org on behalf of Jo Lister
>Sent: Mon 2/27/2006 9:56 AM
>To: www-voice@w3.org
>Subject: SCXML specifications
> 
>
>Dear colleagues,
>
>I read through the SCXML specs (July 2005) with more than casual 
>interest, since I have been attempting to invent a very similar wheel. I 
>found your exercise very useful and I shall attempt to standardise my 
>own evolution on these ideas as they themselves evolve.
>
>I would like to mention 2 features of my own hand-crafted ideas which 
>are so far missing from your specs.
>
>My first goal is to generate a standard for self-describing of the FSM 
>behaviour of delivered systems. This implies not only being able to 
>define the transitions and requests, but also being able to describe the 
>equipment at the same time, so that the same structured data description 
>can be used to control the equipment and to simulate the equipment 
>before it is delivered. For this reason, I am including information on 
>the dynamical behaviour of the plant with the description of the 
>transitions and commands.
>
>Secondly, in the same direction of self-description, the FSM has to come 
>loaded with all the understanding of the supplier. This means that there 
>are documentation nodes buried in the FSM description, capable of 
>providing operational assistance, providing lower details of what is 
>happening in the FSM and to provide general documentation by the supplier.
>
>I would hate to give up on both these directions, and it seems a pity to 
>create a parallel structure to contain this additional information.
>
>I would be interested to know if this is counter your own arguments, or 
>whether such ideas could end up incorporated.
>
>I shall also attempt to establish a working prototype reasonably soon, 
>to test the ideas, and would like to know if you know of people who are 
>trying primitive implementations already.
>
>I do not know if this mail will find the right person. Please at least 
>acknowledge receipt so I do not have to send it again !!
>
>best regards, Jo Lister
>
>
>  
>
-- 

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 Thursday, 2 March 2006 12:35:04 UTC