Re: Soliciting Comments from SCXML Users

Hey Jacob,

there are quite a few tests where you rely on the ecmascript datamodel, but do not set the scxml attribute accordingly. Its default is platform specific and we do use the NULL datamodel per default, therefore more tests than before fail miserably. Would you consider to set the datamodel attribute?

Regards
Stefan


On Feb 10, 2013, at 6:36 PM, Jacob Beard <jbeard4@cs.mcgill.ca<mailto:jbeard4@cs.mcgill.ca>> wrote:

FYI, I have made the changes you suggested and pushed them to github. Furthermore, all tests now validate against scxml.xsd.

If you have any questions or comments, please don't hesitate to ask. Best,

Jake

On Sun, Feb 10, 2013 at 11:12 AM, Jacob Beard <jbeard4@cs.mcgill.ca<mailto:jbeard4@cs.mcgill.ca>> wrote:
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<mailto: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