Re: Soliciting Comments from SCXML Users

Hi Stefan,

Thanks for the feedback. My hope was that the scxml-test-framework could be
adapted for other SCXML implementations, so I'm happy to hear that this was
possible for uscxml.

Your comments are reasonable, and I'll merge them into the test suite.
Specifically, here are my replies:

On Sat, Feb 9, 2013 at 6:08 PM, Stefan Radomski <
radomski@tk.informatik.tu-darmstadt.de> wrote:

>  Hey Jacob,
>
>  I re-ran the tests (informal report below) and there are definitely some
> issues on my part with parallel states (I submitted another respective mail
> to this list, but it was not yet delivered it seems). There are a couple of
> points I'd like to point out:
>
>  - There is no scxml "profile" attribute (anymore?)
>

True. There was a profile property in Draft 7 of the spec, when I first
started developing the test suite. I'll take it out.

In fact, I should probably validate all SCXML test documents against the
latest XSDs included with the spec. There were previously some problems
with the XSDs, but I believe this has now been fixed.


> - The delay[expr] attribute with send is supposed to be in css2 format
> (numeric value with "s" / "ms" prefix afaict)
>

True. I'll fix this.


> - You have several occurrences of a "getData" ECMAScript function that is
> specified nowhere
>

This is a SCION-specific feature. I'll remove or modify these tests.


> - I replied to your framework when there were no more pending delayed
> sends, not after the first stable configuration, this lead to some failures
>

The test suite assumes that the interpreter will accept an event, execute a
macrostep, and will reply with the resulting configuration. If you like, we
can spawn a new thread and have a conversation about whether or not this is
the best approach.


> - You use the type-sensitive "===" operator in your conds, I am not sure
> what to make of it as I stringified all event data and the issue is pretty
> much unspecified
>

I think if the Content-Type header of the HTTP request is
"application/json", it makes sense for the SCXML interpreter to parse the
event data as JSON, and expose it as a js object on the _event.data
property in the ecmascript datamodel. In this case, using strict equality
would be appropriate. I agree that this is currently underspecified.
Language for this could perhaps be added to section D.2.1,  Basic HTTP
Event I/O Processor - Receiving Events.


>
>  With the exception of delayed sends I do think that your overall
> approach is very reasonable and we would support the canonical test cases
> in this format. Our interpreter is obviously still a little rough around
> the edges (or blatantly buggy with respect to parallel and transition order
> :). I will rerun the suite as soon as I ironed out the more obvious bugs.
> In any case, having tests like these is a *tremendous* help to ensure
> proper implementation.
>

Super :)

Best,

Jake