- From: RJ Auburn <rj@voxeo.com>
- Date: Thu, 27 Mar 2008 08:50:24 -0400
- To: "Yakulis, Ross (Ross)" <yakulis@avaya.com>
- Cc: www-voice@w3.org, W3C Voice Browser Working Group <w3c-voice-wg@w3.org>
Ross, As it turns out we were easily able to make a change that is backwards compatible and gets us a state$ variable. Here are the details of what we changed in the specification: --------------------------- START CHANGES ------------------------- * 9.1: Overview - Last paragraph. Existing text: > An <eventprocessor> MAY also declare a state variable attribute. An > <eventprocessor>'s state variable must be declared in the ccxml > scope using a <var>or a <script>. The <eventprocessor> can be > considered, and programmed as, a finite-state-automaton, with the > state variable indicating the automaton's current state or node, and > the <transition>s, driven by incoming events, moving the machine to > a new state and creating side effects along the way. > Add to the end: > If a state variable is not defined in the <eventprocesor>'s > statevariable attribute a default variable named "state$" defined at > the ccxml scope will be used instead. The initial value will be > ecmascript 'undefined'. * 9.2.1.2: <eventprocessor> Attribute Details Change the default value for statevariable from 'none' to 'state$'. * 9.2.2.1: <transition> Overview Change: > If a state attribute is specified on the <transition>, the parent > <eventprocessor> MUST specify a statevariable attribute, and the > current value of the associated variable MUST be equal to one of the > values specified in the state attribute of the <transition>. If no > state attribute is specified on the<transition>, this criteria is > met regardless of whether or not the parent <eventprocessor> > specifies a statevariable attribute to: > If a state attribute is specified on the <transition> the current > value of the associated state variable (as specified in the parent > <eventprocessor>) MUST be equal to one of the values specified in > the state attribute of the <transition>. If no state attribute is > specified on the <transition>, this criteria is met regardless of > the value of the statevariable. Delete: > If the state attribute of <transition> is specified without > <eventprocessor> having a statevariable attribute the interpreter > MUST fail to load the document. * 9.2.2.2: <transition> Attribute Details Delete the following text from the state attribute description: > If the parent<eventprocessor> does not specify a statevariable > attribute, and a <transition> specifies a state attribute, the > interpreter MUST fail to load the document as specified in 9.5.1. --------------------------- END CHANGES ------------------------- The end result is that you will be able to use the state$ syntax but existing applications will not be broken. Please let us know if this resolves your request. If we do not hear from you by April 10th 2008 we will assume this resolution is acceptable to you. Thank you for these valuable comments on the CCXML specification. Best regards, RJ --- RJ Auburn CTO, Voxeo Corporation tel:+1-407-418-1800 On Jan 31, 2008, at 09:10:49, RJ Auburn wrote: > > Ross, > > Thanks for the feedback on this. The working group has tracked this > as ISSUE-325 and will review this to see when we could consider this > for the CCXML specification. It may be a bit late in the process to > go into CCXML 1.0 but we may want to look at this for CCXML 1.1. One > way or another we will let you know the direction we wish to take > once we have had a chance to review the issue internally. > > Thank you and best regards, > > RJ > --- > RJ Auburn > CTO, Voxeo Corporation > tel:+1-407-418-1800 > > > > On Jan 24, 2008, at 16:44:17, Yakulis, Ross (Ross) wrote: > >> Since the event attribute was removed in the last revision of the >> CCXML spec, it follows (to me) that the state variable should be >> implicitly defined at state$ and the attribute statevariable >> removed from eventprocessor? >> >> Ross Yakulis >> > >
Received on Thursday, 27 March 2008 12:51:44 UTC