Just a small modification:
6.2.2.2: <meta> Attribute Details
Current text:
"Either the name or the http-equiv attribute has to be specified. If
neither of them is specified, or if both are specified, an error.fetch event
must be thrown."
Proposed text:
"Either the name or the http-equiv attribute has to be specified. If
neither of them is specified, or if both are specified, CCXML
thread of execution must be terminated and platform must be notified of the
document error."
----- Original Message -----
From: "Hrvoje Nezic" <hrvoje.nezic@envox-lab.hr>
To: <www-voice@w3.org>
Sent: Tuesday, February 06, 2007 6:08 PM
Subject: Comments on CCXML Working Draft 19 January 2007
>
> 6.2.7: <fetch>
>
> Current text:
> "The event is one of fetch.done, which indicates that the identified
> content was fetched successfully, or error.fetch, indicative of a failure
> to fetch the requested content."
>
> Proposed text:
> "The event is one of fetch.done, which indicates that the identified
> content was fetched successfully and in case of CCXML document, XML
> parsing / validation was performed, or error.fetch, indicative of a
> failure to fetch the requested content. "
>
> It is not quite clear from the description of <fetch> what the CCXML
> interpreter should perform before its sends the fetch.done event.
>
> 6.2.2.2: <meta> Attribute Details
>
> Current text:
> " Either the name or the http-equiv attribute has to be specified. If
> neither of them is specified, or if both are specified, an error.fetch
> event must be thrown."
>
> Proposed text:
> ""
>
> I think that this part of specification is in contradiction with section
> 9.5.2: "Document Initialization Errors", which states: "Errors that occur
> during documentation initialization (elements that occur in the CCXML
> document before <eventprocessor>) occur outside of CCXML's event handling
> mechanism. These errors MUST cause the CCXML thread of execution to
> terminate and notify the platform of the document error."
>
> The element <meta> occurs in the CCXML document before <eventprocessor>,
> so it should be handled according to section 9.5.2.
>
>