- From: Barnett, James <James.Barnett@Aspect.com>
- Date: Wed, 1 Mar 2006 10:25:38 -0500
- To: <jo.lister@epfl.ch>, <www-voice@w3.org>
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