RE: The Candidate Recommendation draft of SCXML has been published - call for implementation reports

Yes, 193 and 577 are duplicates, both referring to section D.2.  There is no test for the corresponding passage in D.1, which is:  " If neither the 'target' nor the 'targetexpr' attribute is specified, the SCXML Processor MUST add the event to the external event queue of the sending session."  I will modify test193 to handle this case.

Test233 - fixed

Test286, etc.  The relevant language in the spec is in C.2.7: " When evaluating an <assign> element in the ECMAScript data model, the SCXML Processor MUST replace the existing value at 'location' with the value produced by evaluating 'expr'. If it is unable to do so (for example, if the <assign> element attempts to assign to a read-only attribute), it MUST place the error error.execution on the internal event queue." 
In PySCXML, test286 passes as written.  Does this mean that Johan's implementation specifically tests for an undefined var and raises an error, or is there a difference in his ECMAScript implementation?  

I'll look at your other issues next.

- Jim

-----Original Message-----
From: David Junger [mailto:tffy@free.fr] 
Sent: Saturday, March 15, 2014 8:14 AM
To: Voice Public List
Subject: Re: The Candidate Recommendation draft of SCXML has been published - call for implementation reports

Some initial comments on the tests:

Tests 496 and 577 can be found if you just add the missing 'test' before the number.
Otherwise, 404 errors as Stefan said.

193: why does it now test with the basichttp IOproc instead of regular SCXML? the assertion on the IRP page doesn't say anything about that.
Same for 577. I suppose ONE of those is intended to test basichttp?

233: the XSLT produces cond="" which is always false (I'm using the same tool as Stefan).

286, 311, 331, 401, 402: I thought we agreed that, in the ECMAScript datamodel, assignment to an undeclared property of an existing object would NOT raise an error since ECMAScript itself is perfectly fine with that. The test should try assignment to e.g. "Var1.undefinedProperty" to guarantee an error.

286 and 311 seem to test the exact same thing.

557 and others: beside testing the actual assertion, these tests use <data src> which I have decided not to implement in JSSC. What I do in these cases is to remove the part that uses <data src> and use the result of the modified test, so you know if JSSC actually supports the tested feature (e.g. parsing XML data in 557), whereas using the original test would always fail and require a comment whose information is better expressed by the failure of the test that actually tests for <data src>.
Alternatively, I could rewrite the <data src> part to use <jssc:fetch>.
Anyway, I don't expect you to change the tests, just tell me what you'd prefer that I do about this.

561: the comment in the file and assertion on the IRP page say it tests JSON parsing, but the actual code still tests XML parsing, as in previous versions of this file.

			David

Received on Monday, 17 March 2014 15:26:08 UTC