RE: SCXML specifications

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


-- 
Dr Jo Lister
Adjoint Scientifique à la Direction
CRPP-EPFL, Station 13
1015 Lausanne, Switzerland
Tel: +41-21-693-3405 / 3487
Fax: +41-21-693-5176
Email: Jo.Lister@epfl.ch

Visiting Researcher at ITER Garching
Tel:+49-89-3299-4175

Received on Wednesday, 1 March 2006 15:22:58 UTC