- From: Michael Traut <mtraut@intarsys.de>
- Date: Fri, 19 Sep 2008 10:20:24 +0200
- To: "Barnett, James" <James.Barnett@aspect.com>
- Cc: www-voice@w3.org
- Message-ID: <OFCFC4586D.B633848B-ONC12574C9.002A6A26-C12574C9.002DD095@intarsys.de>
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...:-)
2) btw. there is the same wording in paragraph 3.1.2...
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)
By the way - what is the reason to make each state id document wide unique
instead of parent wide (wich would result in "root.restore" as the id for
the history state)?
4) Yes, i appreciate the concept of profile and i can workaround this
issue - but its a workaround. The extension of actions semantics is
possible on a per element base, conditions not. Again an example from my
functor world:
This would do the job
<scxml name="Test" initial="A" version="1.0">
<state id="A">
<onentry>
<perform type="JavaScript" source="app.alert('enter A')"/>
</onentry>
<transition event="a" cond="computeCondition()" target="B">
<perform type="JavaScript" source="app.alert('to B')"/>
<perform type="JavaScript">
<source>
/* some complex source that should not mess with xml attribute
delimiters.../*
var a = "foo'bar";
</source>
</perform>
</transition>
</state>
...
</scxml>
<perform> is my generic, XML based statement. I can switch, on each
instance from such types like "JavaScript", "Debug", "Python",...
The condition on the other hand is tied to a single language and forced in
an xml attribute syntax. I have no way to get this in a more complex
element. This would be heaven:
<scxml name="Test" initial="A" version="1.0">
<state id="A">
<onentry>
<perform type="JavaScript" source="app.alert('enter A')"/>
</onentry>
<transition event="a" target="B">
<guard>
<perform type="JavaScript" source="computeCondition()"/>
</guard>
<ontrigger>
<perform type="JavaScript" source="app.alert('to B')"/>
<perform type="JavaScript">
<source>
/* some complex source that should not mess with xml attribute
delimiters.../*
var a = "foo'bar";
</source>
</perform>
</ontrigger>
</transition>
</state>
...
</scxml>
Simply putting executable action always in a container of its own (as in
onentry) would bring the extensibility that i need (and gives room for
further extension on the transition later on). The roles of the actions
within transition is kind of underspecified.
Once again, many thanks for your reply and thoughts about my concerns.
kind regards,
Michael Traut
---------------------------------------------------------------------
Fon: +49 721 38479-12
Fax: +49 721 38479-60
Mobil: +49 172 7232017
Mail: mtraut@intarsys.de
---------------------------------------------------------------------
intarsys consulting GmbH
Bahnhofplatz 8, D-76137 Karlsruhe
Geschäftsführer:
Dr. Bernd Wild, Karl Kagermeier, Michael Traut
Sitz der Gesellschaft: Karlsruhe
Registergericht: Amtsgericht Mannheim HRB 107535
Web: http://www.intarsys.de
"Barnett, James" <James.Barnett@aspect.com> schrieb am 18.09.2008
18:08:55:
> Michael,
> Concerning your questions:
> 1) We have discussed this issue within the group several times
> and each time the conclusion has been that in an XML language it is
> useful to have a distinct root element that is not equivalent to its
> descendant elements. We haven?t found a compelling argument in
> either direction, though, and will probably revisit the issue again.
> If you put a single top-level state as the unique child of <scxml>,
> you can get the same behavior as if <scxm> was itself a state.
> 2) You?re right and the phrasing is inaccurate. The <onentry>
> element will be executed. The <initial> element allows for
> additional executable content which will be executed only on default
> entry (while the <onentry> is executed no matter how the state is
> entered.) We?ll change the wording in the next draft.
> 3) That?s a very interesting question. We haven?t considered
> whether the history state may be the value of the initial attribute.
> In general, we have always assumed that you do need to specify the
> history state directly as the target of the transition. For more
> dynamic behavior, you can jump back to a previous state without
> specifying the history state ID directly in the transition by using
> the ?anchor? attribute.
> 4) You should be able to define a profile that will give you
> any conditional language you want. For example, the XPath profile
> specifies that conditional expressions are XPath2 expressions, while
> the ECMA profile specifies them as ECMAScript expressions. You can
> define a profile that allows your functors as conditional
> expressions. The only restrictions are: 1) they must return a
> Boolean value 2) they must not have side-effects.
>
> - Jim
>
>
> From: www-voice-request@w3.org [mailto:www-voice-request@w3.org] On
Behalf Of
> Michael Traut
> Sent: Thursday, September 18, 2008 10:58 AM
> To: www-voice@w3.org
> Subject: SCXML specification
>
>
> Dear sirs,
>
> currently i am about to move my statemachine engine towards the
> SCXML standard. There are some issues and questions i found and i
> hope you can help me to a better understanding or improvement of the
> upcoming standard.
>
> 1) 3.1 - scxml
>
> why is the definition "half hearted" recursive? the root may not contain
> - "onentry" this would be a natural place to put
> initalization action, as opposed to the "script" extension
> - "onexit" the same as above - just for symmetry
> - "transition" transitions that are inherited by the states
> within the "compound state" scxml
> - "history" - very important!! currently i see no way to
> express the possibiltiy to enter a whole machine at a defined state.
Why?
>
> in my opinion the root as currently defined is a (compound) state
> itself and should allow for that.
>
> 2) 3.5 - initial
>
> the description of the semantics is somehow misleading "If the
> initial attribute is specified, the specified state willbe entered,
> but no executable content will be executed". I assume, the "onentry"
> action is executed anyway.
>
> 3) 3.9 - history
>
> maybe this is obvious, but it took me some time to figure out from
> the pseudo semantics (maybe erroneous): If i enter a compound state
> there should be a way to enter a historical state without specifing
> the history state directly. This decision may be up to the state
> node himself. This can be done (am i right?) by specifying the
> history state as the initial state of the compound state?
>
> 4) 3.3 - transition
>
> while we have a very easy way of extending the action / executables,
> this is much more problematic with conditions. My current
> implementation works with generic "Functor" objects that can be
> plugged anywhere the spec allows actions. This is fine as they can
> be expressed as elements of the form <perform type="??"
> source="??"/>. These functors allow an "implementation language" on
> a per instance base. This syntax is not suitable for conditions, as
> these are restricted to string expressions. It would be a great
> improvement if i were able to express conditions as functors. this
> would mean that i need an element based definition.
>
> I am looking forward for your reply, many thanks.
>
> kind regards,
> Michael Traut
>
> ---------------------------------------------------------------------
> Fon: +49 721 38479-12
> Fax: +49 721 38479-60
> Mobil: +49 172 7232017
> Mail: mtraut@intarsys.de
> ---------------------------------------------------------------------
>
> intarsys consulting GmbH
> Bahnhofplatz 8, D-76137 Karlsruhe
> Geschäftsführer:
> Dr. Bernd Wild, Karl Kagermeier, Michael Traut
> Sitz der Gesellschaft: Karlsruhe
> Registergericht: Amtsgericht Mannheim HRB 107535
> Web: http://www.intarsys.de
Received on Friday, 19 September 2008 08:21:11 UTC