W3C home > Mailing lists > Public > www-voice@w3.org > January to March 2009

Re: RE: SCXML specification

From: Rahul Akolkar <rahul.akolkar@gmail.com>
Date: Mon, 23 Mar 2009 16:48:25 -0400
Message-ID: <ce1f2ea80903231348p20d6a56cwf7989b47b6295f3b@mail.gmail.com>
To: www-voice@w3.org
Michael,

As Jim mentioned in his response sent March 11th, sorry it took us a
while to schedule time to discuss your email.  I would like to respond
to your points (1) and (3) below.  The idea of treating the SCXML root
element as just another (composite) state has been brought up before
in the WG, and is scheduled for further discussion in the SCXML 1.1
specification timeframe.  We think that this will require careful
discussion, and many changes to the specification prose, schema and
normative tests (as Jim also mentioned, we are reluctant to undertake
any new features or major changes for SCXML 1.0).  Meanwhile, as you
point out below, you can continue to express the semantics you
describe by shifting the transition or history element down into a
composite state element.

Best,
-Rahul


On Fri, Sep 19, 2008 at 4:20 AM, Michael Traut <mtraut@intarsys.de> wrote:
>
> Hi James,
>
> many thanks for the prompt reply.
>
> 1) I understand that keeping the language "clean" is an important issue -
> perhaps one could clarify the thinking and best practices behind the design.
> I actually saw already "scxml" code, that had "transition" elements included
> in the root. So, it seems an obvious question and many adopters may think of
> this as "just forgotten to mention". The evolution of dialects even before
> the final release is distracting...:-)
>
<snip/>
>
> 3) This issue is especially important with the root itself. I embed the
> machine in documents, carrying their business process with them. Loading the
> document can restore the state the machine was in when last saved. But from
> the outside of the spec at initial startup i have no way of expressing that
> the machine should restore at the top level. It is up to the machine to go
> to its initial state or history state. So the machine designer should be
> able to express this.
>
> This would do the job (informal syntax).
>
> <scxml name="Test" initial="restore" version="1.0">
>
>    <history id="restore">
>       <transition target="A"/>
>    </history>
>
>   <state id="A">
>   </state>
> ..
> </scxml>
>
> While with this i always get to "A"
>
> <scxml name="Test" initial="A" version="1.0">
>
>   <state id="A">
>   </state>
> ..
> </scxml>
>
> This is kind of "bundled" with 1, as i currently have only flat machines - i
> need this history element in the root, too. Shifting this one element down
> to express the semantics seems a bit clumsy
>
> <scxml name="Test" initial="restore" version="1.0">
>
>    <state id="root" initial="A">
>
>        <history id="restore">
>          <transition target="A"/>
>       </history>
>
>       <state id="A">
>       </state>
>
>    </state>
>
> </scxml>
>
> By any way, i need the possibility to anonymously enter the history at
> initial startup without triggering an additional event from outside (as the
> client does not know about this construct)
>
<snap/>
Received on Monday, 23 March 2009 21:41:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 23 March 2009 21:41:30 GMT