- From: Jim Barnett <Jim.Barnett@genesyslab.com>
- Date: Fri, 12 Apr 2013 13:46:53 +0000
- To: Stefan Radomski <radomski@tk.informatik.tu-darmstadt.de>
- CC: Voice Public List <www-voice@w3.org>
Stefan, The prose in 5.10.1 is wrong. I have updated it to say "sendid: If the sending entity has specified a value for this, the Processor MUST set this field to that value (see D Event I/O Processors for details). Otherwise, in the case of error events triggered by a failed attempt to send an event, the Processor MUST set this field to the send id of the triggering <send> element. Otherwise it MUST leave it blank." - Jim -----Original Message----- From: Stefan Radomski [mailto:radomski@tk.informatik.tu-darmstadt.de] Sent: Friday, April 12, 2013 9:45 AM To: Jim Barnett Cc: Voice Public List Subject: Re: updated SCXML draft The language with regard to _event.sendid is still confusing: 5.10.1: sendid . In the case of error events triggered by a failed attempt to send an event, the Processor must set this field to the send id of the triggering <send> element. Otherwise it must leave it blank. D.1: The 'sendid' field of the event raised in the receving session must match the sendid in the sending session, if the author of the sending session specifes either the 'id' or 'idlocation' attribute. If the author does not specify either the 'id' or 'idlocation' attribute, the 'sendid' field must be left empty. I am not sure what's intended here, I used to auto-generate an id if none was specified or idlocation was given, but that is in conflict with the stanza from 5.10.1. Best regards Stefan On Apr 10, 2013, at 7:37 PM, Jim Barnett <Jim.Barnett@genesyslab.com> wrote: > W3C Process requires us to record and track all issues raised by the public once we reach Last Call Working Draft status. The discussion on this list has been so active over the last few months that it is hard to track individual 'issues'. Therefore I have decided that the best thing to do is to post a draft containing all the revisions that I have made due to the discussions (along with a diffed version, to make it easy to locate the changes.) This is not an official publication, but a preview of the next draft. > > I would like to ask anyone who has commented in the last few months to take a look at the draft and let me know if: > 1. This draft has addressed your concerns, or > 2. If there are specific issues that you think have not been adequately addressed > > If I don't hear from you (i.e., from a specific commenter) within two weeks, I will assume that the draft has addressed your issues and that you are willing to let the specification proceed towards Recommendation status in its current form. (Please note that issues about the test suite or possible standard implementations are not relevant here. We are just concerned with the specification as a document.) > > Basically, now is the time to speak up if you want to keep an issue open. You will certainly have further opportunity to comment once this draft is officially published, but I think that we can get to Recommendation faster if we can handle the issues that have already been raised before we publish another public draft (which will also be called "Last Call Working Draft"). > > > Here is the new draft: http://www.w3.org/Voice/2013/scxml-irp/SCXML.htm > Here is a diffed version: http://www.w3.org/Voice/2013/scxml-irp/SCXML_Diff.htm (There are changes throughout the document, but there's a heavy concentration of them in the algorithm and ECMAScript data model.) > > Let me know if you have problems accessing either of these docs. > > - Jim
Received on Friday, 12 April 2013 13:47:17 UTC