Re: Soliciting Comments from SCXML Users

This is done.

Feel free to send more feedback. Best,

Jake

On Mon, Feb 11, 2013 at 1:42 PM, Stefan Radomski <
radomski@tk.informatik.tu-darmstadt.de> wrote:

>  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> 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>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> 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
>>
>>
>
>