W3C home > Mailing lists > Public > www-voice@w3.org > July to September 2007

Re: Comments on CCXML Working Draft 19 January 2007 (ISSUE-231)

From: RJ Auburn <rj@voxeo.com>
Date: Thu, 5 Jul 2007 11:34:11 -0400
Message-Id: <C0C06CFF-8722-4B28-92EF-D25C4D386308@voxeo.com>
Cc: <www-voice@w3.org>, "W3C Voice Browser Working Group" <w3c-voice-wg@w3.org>
To: Hrvoje Nezic <hrvoje.nezic@envox-lab.hr>

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, 5 July 2007 15:34:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 5 July 2007 15:34:44 GMT