RE: SCXML specifications

Raxit,
  Section 6.5 of the specification gives some examples of  what I think
you are proposing, namely adding CCXML call-control functionality to
SCXML.  So custom tags are added to create a call, answer a call, etc.
This is a kind of customization that SCXML definitely intends to
support.  However, when we do this kind of extension, the resulting
language has SCXML syntax.  It is impossible to define CCXML -
specifically, a language with CCXML _syntax_ - as an extension to SCXML.


In short, we  can define a language with CCXML functionality as an
extension to SCXML.  Furthermore, we can use XSLT to translate CCXML
markup into this SCXML extension.  But we cannot define CCXML as a
language (both syntax and semantics) as an extension to SCXML.

- Jim

-----Original Message-----
From: Sheth Raxit [mailto:raxit@phonologies.com] 
Sent: Thursday, March 02, 2006 7:48 AM
To: Barnett, James
Cc: www-voice@w3.org
Subject: 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 Friday, 3 March 2006 08:41:21 UTC