- From: RJ Auburn <rj@voxeo.com>
- Date: Thu, 13 Sep 2007 10:37:18 -0400
- To: Hrvoje Nezic <hrvoje.nezic@envox-lab.hr>
- Cc: "'www-voice@w3.org'" <www-voice@w3.org>, W3C Voice Browser Working Group <w3c-voice-wg@w3.org>
Hrvoje, As we have not heard any comments back on our response from you we are closing this issue out in our tracking. Thank you very much for the feedback on the CCXML specification. RJ On Jul 26, 2007, at 10:18 :55, RJ Auburn wrote: > > Hrvoje, > > I wanted to check in with you on this and see if you had any > further comments on the working groups spec changes and comments. > If we do not hear otherwise by Aug 9th we will consider this issue > closed. > > Thanks again for all the comments and reviews. > > RJ > > ISSUE-231 > > On Jul 5, 2007, at 11:34 :11, RJ Auburn wrote: > >> >> Hrvoje, >> >> Thanks for the reply. The working group has review these and we >> have some comments inline. >> >> On May 18, 2007, at 11:57 AM, Hrvoje Nezic wrote: >> >>> RJ and the working group, >>> >>> Thanks for reviewing and answering my comments. >>> >>> Regarding comments about <fetch> element, your answer >>> is completely acceptable to me. >>> >>> Regarding <meta> element I still have some questions and doubts. >>> >>> You said: >>> "One clarification to your comment: The detection of the error >>> condition related to invalid use of attributes is something that >>> would happen during XML parsing and is therefore handled as >>> described >>> in section 9.5.1 (fetching and compilation errors) rather than 9.5.2 >>> (Document Initialization Errors)." >>> >>> 1) >>> If the statement: "the detection of the error condition related >>> to invalid use >>> of attributes is something that would happen during XML parsing" >>> applies to the whole CCXML specification, I think it is very >>> important >>> and it should be a part of the specification. >>> >>> If I understand it well, it applies to the cases when exactly one of >>> several attributes must be present (like in <meta>, >>> <dialogstarted>, <send>, >>> <script> and <move>) and possibly to some other cases. I think >>> the specification >>> should explicitly state that such cases must be handled during >>> XML parsing. >> >> To help make this more clear we have added the following text to >> section 9.5.1 to cover this case: >> >> >>> 9.5.1: Fetching & compilation errors >>> >>> Errors that occur in trying to load and compile a CCXML document, >>> such as the inability to fetch the CCXML page or statically >>> referenced ECMAScript content, XML parsing or validation errors >>> >>> *NEW* (Including checks for mutually exclusive attributes or any >>> other constraints as defined in the this specification, it's >>> attribute tables, schema or DTD), *END NEW* >>> >>> compilation errors or other errors that occur as a result of >>> trying to fetch and run a CCXML page prior to document >>> initialization >>> >> >> Does this help make it more clear? >> >> >>> 2) >>> The specification usually states that in such cases "an >>> error.fetch must be thrown". >>> I think this is not good enough, because according to 9.5.1, >>> there are three cases, >>> depending on how the fetching has been initiated: >>> a) by <createccxml> --> throw error.createccxml to the parent >>> session >>> b) by <fetch> --> throw error.fetch to the same session >>> c) by an incoming call or HTTP --> terminate the session >>> >>> So I think that specification should state something like: >>> "an error.fetch or error.createccxml must be thrown, or the session >>> must be terminated (see 9.5.1)". >> >> Because of the number of locations and variants we have actually >> removed the additional text about error.fetch from most places in >> the spec and are only defining it in 9.5.1 as otherwise there are >> many places where this needs to be. >> >>> 3) >>> This also applies to <meta>, so my original proposal was not >>> correct; >>> the description of attributes "content" and "http-equiv" should >>> contain >>> the phrase "an error.fetch or error.createccxml must be thrown, >>> or the session must be terminated (see 9.5.1)". >> >> Please see last point about centralizing the error handing text in >> the specification. >> >>> 4) >>> In description of the <script> element, "src" attribute, the >>> specification states: >>> "Note that the value of the src attribute must not be an >>> ECMAScript expression >>> in order to allow it to be resolved at compile-time. If the >>> script cannot be fetched >>> the implementation must throw an error.fetch event." >>> >>> I think this needs clarification. Why the src attribute must be >>> resolved at the >>> compile-time? Does it mean that all <script>s with the src attribute >>> should be fetched at compile time? If this is the case, I think >>> the specification should >>> explicitly state it. >>> >>> Should the statement "If the script cannot be fetched the >>> implementation must throw >>> an error.fetch event" be also treated (and changed to) something >>> like: >>> "If the script cannot be fetched an error.fetch or >>> error.createccxml must be thrown, >>> or the session must be terminated (see 9.5.1)." ? >> >> Script is indeed a special case. To clean this up we have removed >> the specific error.fetch message (inline with the above changes >> and have pointed at 9.5.1 to define the behavior. We have also >> added an informative section explaining some of the reasons that >> script is the way it is: >> >> >>> INFORMATIVE NOTE: The <script> element's resource loading model >>> is a bit different than the rest of CCXML for a number of >>> reasons. Because CCXML and ECMAScript applications can be CPU >>> intensive to compile we define <script>'s src attribute (defining >>> the URI of the document to load) to be a static string instead of >>> a dynamically valued ECMAScript result. This allows >>> implementations to load ECMAScript content at CCXML document load >>> time and perform compiling and/or caching of the resulting >>> ECMAScript code. We do however recognize that there are cases >>> where a CCXML application needs to load a dynamic ECMAScript >>> resource, for this reason applications can use the the <fetch> >>> element to asynchronously load a resource and then execute it by >>> referencing it's fetchid in the the <script> element. >>> >> >> >> Do the above changes address your concerns? >> >> Best regards, >> >> RJ >> >> --- >> RJ Auburn >> CTO, Voxeo Corporation >> tel:+1-407-418-1800 >> >> >> >> >> >> > >
Received on Thursday, 13 September 2007 14:37:49 UTC