RE: ISSUE-825: comments from Darmstadt [SCXML-LC-Comments]

Stefan,
  On the issue of the conformance test, a comprehensive set of tests will be provided as part of the Implementation Report Test Plan when we publish the Candidate Recommendation of SCXML.  Strictly speaking, these are not "conformance tests" since their purpose is not to validate a specific implementation but to prove that the specification can be implemented.  However, as a practical matter, they're a pretty good imitation of a conformance test.  We would be  delighted if you would  run them and submit a report.  

I'm not sure when the tests will be published.  If we receive comments that lead us to make substantive changes to the specification, we will have to publish another Last Call working draft.  Once all comments have been dealt with and we are confident that no further changes are necessary, we will publish the Candidate Recommendation, along with the tests.

We will respond to your other comments once we have had a chance to study them.  If you will included "ISSUE-825" in the subject line of any subsequent correspondence, it will help us keep track of thread automatically.  

Best,
Jim 

-----Original Message-----
From: Voice Browser Working Group Issue Tracker [mailto:sysbot+tracker@w3.org] 
Sent: Tuesday, January 22, 2013 9:13 AM
To: w3c-voice-wg@w3.org; www-voice@w3.org
Subject: ISSUE-825: comments from Darmstadt [SCXML-LC-Comments]

ISSUE-825: comments from Darmstadt [SCXML-LC-Comments]

https://www.w3.org/Voice/Group/track/issues/825


Raised by: James Barnett
On product: SCXML-LC-Comments

from Stefan Radomski [radomski@tk.informatik.tu-darmstadt.de]

Hey there,

[....]
 
So if you are using or have used SCXML, please take the time to send us your comments.  The more comments we get, the more confident we can be that we are producing a sound and useful standard.

we implemented the SCXML draft (or large parts of it) in C++[1]. We do feature an ecmascript (v8) and an experimental prolog (SWI) data model. The overall state of the implementation is still rather crude and very much undocumented but it builds fine on MacOSX, Linux and every now and then on Windows.

I guess what we missed the most is a set of conformance tests as some ..scxml files with sequences of configurations the interpreter is supposed to go through and internal events to raise. Especially the logic around "filterPreempted" is still somewhat fuzzy to us.

Apart from that, there are some areas in the draft where we could imagine some improvements. Just off the top of my head:
- When you use the "Null" datamodel, you cannot use the <param> element to pass even literal strings to e.g. an invoker as both "expr" and "location" are subject to evaluation by the datamodel. Maybe the obvious "value" attribute with a literal string could be included. 
- Sending events via the basichttp ioprocessor should allow for the other party to send events in the response.
- Is there a reason scopes in the datamodel were disallowed so explicitly?
- When evaluating foreach with "item" already defined in the datamodel, is it to be reset after foreach ends?
- When embedding an interpreter, #_parent could be specified to send events to the embedding application.

I am sure we will run into many more problems once interoperability with other interpreters becomes an issue.

Best regards
Stefan

[1] https://github.com/tklab-tud/uscxml


---
FB20 Telecooperation | Darmstadt University of Technology Hochschulstr. 10 | D-64289 Darmstadt Germany | Room S2|02 / A108 Tel +49 (6151) 16-6670 | Fax +49 (6151) 16-3052

Received on Tuesday, 22 January 2013 14:21:40 UTC