RE: updated SCXML draft

Chris,
I think that the problem can be demonstrated with an even simpler case:  create a transition with two target states that don't have a parallel ancestor.  The algorithm will put you in both of them.  The reason for this is that we explicitly decided that the algorithm would not check for valid state configurations because doing so would complicate it too much.  The spec handles this problem in section 3.11 where it defines legal state configurations  and says that a valid SCXML document must put the state machine only in legal state configurations.  So the example that you describe as well as the one I gave above are invalid documents.  (The spec also says that the behavior in the case of invalid documents is undefined.  This is designed to give implementations some wiggle room to decide when to ignore problems, or reject the document or re-write it on the fly, etc.)

So, basically, given a valid document, the algorithm works correctly (I hope).  Given an invalid one, all bets are off.

In a practical implementation, I would be inclined to check for valid state specifications at document creation/validation time, rather than slow down the runtime.  In fact, if I were better at XPath I think that I could extend the -strict schemas to detect and reject transitions that go to invalid state specifications.   (As it stands, even the non-strict schemas catch a number of invalidities that would cause the algorithm to blow up - for example a transition to a target state that doesn't exist.)

Anyhow, that is our reasoning.  Perhaps I should add a comment to the algorithm making this clear.


-          Jim

From: chris nuernberger [mailto:cnuernber@gmail.com]
Sent: Wednesday, April 10, 2013 9:03 PM
To: Jim Barnett
Cc: Voice Public List
Subject: Re: updated SCXML draft

I think there are possible problems with the enter state algorithm depending on how insanely people use initial.  A limited initial that could only address direct children of the current node would eliminate this but without that a sufficiently insane initial config combined with a multitarget transition could put the state machine into configurations where multiple states are active under the same non parallel state.

The potential problem is that the algorithm completely activates parallels before running all the targets in a transition.  So someone could potentially construct a transition that causes the parallel to activate using its initial configuration with the first target and then the next target in the transition would activate a specific non-initial state underneath the parallel.

I don't know if the list cares or not and I do not propose immediately an algorithm to address this.  It would need to two-pass per transition, and it would be more verbose than the current algorithm.

This transition couldn't in and of itself be considered invalid because, without interleaving initial activations into target activates it wouldn't cause an invalid state.  But the combination of state initial settings interleaved with target activations could potentially cause a state machine built using the provided algorithm to be in two states in a non-parallel subgraph.

Chris

On Wed, Apr 10, 2013 at 11:37 AM, Jim Barnett <Jim.Barnett@genesyslab.com<mailto:Jim.Barnett@genesyslab.com>> wrote:
W3C Process requires us to record and track all issues raised by the public once we reach Last Call Working Draft status.  The discussion on this list has been so active over the last few months that it is hard to track individual 'issues'.   Therefore I have decided that the best thing to do is to post a draft containing all the revisions that I have made due to the discussions (along with a diffed version, to make it easy to locate the changes.)   This is not an official publication, but a preview of the next draft.

I would like to ask anyone who has commented in the last few months to take a look at the draft and let me know if:

1.        This draft has addressed your concerns, or

2.       If there are specific issues that you think have not been adequately addressed

If I don't hear from you (i.e., from a specific commenter) within two weeks, I will assume that the draft has addressed your issues and that you are willing to let the specification proceed towards Recommendation status in its current form.   (Please note that issues about the test suite or possible standard implementations are not relevant here.  We are just concerned with the specification as a document.)

Basically, now is the time to speak up if you want to keep an issue open.  You will certainly have further opportunity to comment once this draft is officially published, but I think that we can get to Recommendation faster if we can handle the issues that have already been raised before we publish another public draft (which will also be called "Last Call Working Draft").


Here is the new draft:  http://www.w3.org/Voice/2013/scxml-irp/SCXML.htm
Here is a diffed version:  http://www.w3.org/Voice/2013/scxml-irp/SCXML_Diff.htm  (There are changes throughout the document, but there's a heavy concentration of them in the algorithm and ECMAScript data model.)

Let me know if you have problems accessing either of these docs.


-          Jim




--
A foolish consistency is the hobgoblin of little minds - Emerson