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

Zjnue,
You are right.  I've fixed test 193 to use the SCXMLEventProcessor.


-          Jim

From: Zjnue Brzavi [mailto:zjnue.brzavi@googlemail.com]
Sent: Friday, March 21, 2014 6:01 PM
To: Jim Barnett
Cc: David Junger; Voice Public List
Subject: 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.

Hi Jim,
I'm just catching up with this change and it appears the incorrect send type was specified for test 193.
Right now the type is specified as http://www.w3.org/TR/scxml/#<http://www.w3.org/TR/scxml/>BasicHTTPEventProcessor

However, the specification for <send> without target / targetexpr says the following:

Where type is BasicHTTPEventProcessor:
"If neither the 'target' nor the 'targetexpr' attribute is specified, the SCXML Processor MUST add the event error.communication to the internal event queue of the sending session."
Where type is SCXMLEventProcessor:
"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."
It appears test 193 is aiming to test the latter scenario, which means the send type should be SCXMLEventProcessor instead of BasicHTTPEventProcessor.
Here's the diff: https://github.com/zjnue/hscxml/commit/df76996837fe7e9b9f4509f3dbb73fe31bca74cb
Best regards,

Zjnue