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

Re: CCXML: comment on ISSUE-732

From: Petr Kuba <kuba@optimsys.cz>
Date: Tue, 03 Aug 2010 14:06:46 +0200
Message-ID: <4C580656.5040603@optimsys.cz>
To: Chris Davis <davisc@iivip.com>
CC: www-voice@w3.org

The implementation Chris describes is probably the best way to follow 
the specification and pass the test.

On the other hand, it is definitely not as optimized as it could and 
should be. That's why we suggest to change the Specification and the 
Test Suite as described below.

Imagine that you are loading a script in <transition> and that the 
loading takes 5 seconds. Then the CCXML session is blocked for these 5s. 
If for instance a VoiceXML session exits during this time the CCXML 
session cannot handle the dialog.exit event and a users hears nothing 
for 5s.

Therefore it should be possible to load ALL scripts at document load 
time and handling of loading errors should be fixed in the Specification.


On 2.8.2010 19:23, Chris Davis wrote:
> 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.
> Regards,
> Chris
>> 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
Received on Tuesday, 3 August 2010 12:07:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:03:57 UTC