CCXML: comment on ISSUE-732

Hello www-voice,

We pass the test because we only load <script> at *document load time* 
if it is a child of <ccxml> as opposed
to being a child of <transition> as in this case. The combination of the 
quoted text and the rule that we must
throw an error.fetch make this the only way to create a conforming 
implementation that does some level of optimization.


> Hello www-voice,
> In 8_2_3, the following code is used to load a script:
> 		<script src="sleeper.ircgi" timeout="1s"/>
> Since the sleeper.ircgi script contains 20s delay loading of the script must fail.
> Our question is how to handle this loading error. The Specification, Section contains the following note:
> "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."
> We load the script content at the CCXML document load time as recommended. The loading error results in throwing error.createccxml because we were not able to load the CCXML document or one of its parts. The CCXML document interpretation is not started at all.
> We believe that the test script 8_2_3_A.txml is incorrect when it expects the error.fetch event to be thrown.
> Please clarify on this.
> Thanks,
> Petr

Chris Davis
Interact Incorporated R&D

Received on Monday, 2 August 2010 17:24:12 UTC