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

Stefan,
We have discussed your comments and have the following responses:

First, on the issue of test sets, we are investigating the possibility of publishing an early version of our test set.  Even if this turns out not to be possible, the tests will be published along with the Candidate Recommendation Draft (this is where W3C process requires them.)

On your more specific comments:

- 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.
>> In general, the datamodels in the specification are intended as examples, with the Null datamodel intended to show the bare minimum that is required.  If you want a data model that extends the Null model to allow literals, you can easily define one.  If enough groups find it useful, we will include it in a future version of the specification.  In general, our intent is that groups will define their own data models.

- Sending events via the basichttp ioprocessor should allow for the other party to send events in the response.
>> This is an interesting idea, but we're not convinced that it would be simple to define, and we are reluctant to undertake it when we're trying to finish version 1.0.  We suggest that you implement this as an extension and then report back to this mailing list.  This is certainly something that we would consider introducing in future versions, particularly if other implementations found it useful.    As with datamodels, we expect implementations to define their own event I/O processors beyond those defined in the specification.

- Is there a reason scopes in the datamodel were disallowed so explicitly?
>> Upon consideration, we don't think that there is, and we will drop this requirement from the specification.  However, we will still define that ECMASript and XPath models as unscoped, because we have found them useful in that form.  None of us have experience using scoped datamodels with SCXML, and we don't know what issues may arise, but, now that we think about it, we see no reason to keep other people from experimenting.  If you do experiment with a scoped model, please let us know how it works out.

- When evaluating foreach with "item" already defined in the datamodel, is it to be reset after foreach ends?
>> No.  As the specification now stands, "item" is not reset.

- When embedding an interpreter, #_parent could be specified to send events to the embedding application.
>> The standard does not define the concept of the embedding application or the interface to it.  Therefore we don't think it makes sense for the specification to define how <send> returns data to something so ill-defined.  However, you are free to define an extension in your implementation whereby '#_parent' to has this meaning.  This definition won't be portable across implementations, of course, but it is highly unlikely that any communication with the embedding application will be portable, given the variety of environments in which SCXML could be used.
However, if multiple implementers find that the interface to the embedding environment can be standardized in a useful way, it is certainly something that we would consider in a future draft of the specification.

>> As you can see, our response to many of your suggestions is that you should  implement them as extensions.  One reason for this is that W3C process requires us to demonstrate at least two implementations of each feature of a standard.  Thus, even if we made some of the changes that you suggest, they would be removed from the specification at a later stage unless some other group decided to implement them as well.

Please let us know if you are satisfied with our responses to your comments.  If we do not hear from you within two weeks, we will assume that you are.  (W3C process requires that we formalize the discussion of comments in this manner.)