W3C home > Mailing lists > Public > www-voice@w3.org > January to March 2013

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

From: Stefan Radomski <radomski@tk.informatik.tu-darmstadt.de>
Date: Fri, 8 Feb 2013 13:04:08 +0000
To: Jim Barnett <Jim.Barnett@genesyslab.com>
CC: "www-voice@w3.org" <www-voice@w3.org>
Message-ID: <6A775895400B8040A331C2963964820C1952FA42@exchange01.tk.informatik.tu-darmstadt.de>
Excuse my late reply, I have been on vacation.

On Jan 30, 2013, at 11:04 PM, Jim Barnett <Jim.Barnett@genesyslab.com<mailto:Jim.Barnett@genesyslab.com>> wrote:

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

I guess the latest discussions on this ML were all in favor of getting some early test cases, if even only for the basic functionality and not considering border cases. Please investigate accordingly :)

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

The key point is that the <param> element is of no use with the NULL datamodel, I just wanted to be clear on that.

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

We are in the process of implementing a simple REST interface on top of the basichttp ioprocessor and will let you know how that turned out.

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

My colleague Dr. Schnelle-Walka maintains the jVoiceXML implementation and its datamodel is scoped so we were wondering whether there was something more to it. We are fine with unscoped datamodels for SCXML though.

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

We did in fact implement it and it seems to work fine. Considering that "#_parent" has this semantics for SCXML documents invoked by a SCXML IOProcessor, we thought it fitting to return events to "the invoking component". But you are right of course that embedded platforms will most likely offer non-portable extensions.

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

Consider us formally satisfied with these comments.

Best regards
Received on Friday, 8 February 2013 13:04:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:07:43 UTC