Re: April CCXML: <fetch> clarification [cc] ISSUE-718

RJ,

Thanks for your clarification, it really helps.

Regards,
Petr


On 16.9.2010 14:48, RJ Auburn wrote:
> Petr:
>
> Comments are inline below:
>
>> On May 28, 2010, at 10:48 AM, Petr Kuba wrote:
>>> 1) Section 6.2.7.1 states:
>>>
>>> "If the platform does not support the content type returned from a
>>> <fetch>  request but the fetch does successfully complete (for example
>>> HTTP 2xx response code) the platform MUST still throw a fetch.done event
>>> for the fetchid."
>>>
>>> I believe that this statement is invalid if the mode value is
>>> "processed". In this case the following statement should be applied:
>>>
>>> "Note that even if content is successfully fetched, errors in processing
>>> fetched content (for instance, a CCXML document with a syntax error) may
>>> result in an error.fetch being thrown."
>>>
>>> Please clarify this.
>
>
> The intent is indeed that if you are in processed mode that you would get an error event if something like parsing failed even if the HTTP request completed.
>
>>> 2) 6.3.2 fetch.done:
>>>
>>> How shall content attribute behave in processed mode? The description
>>> states:
>>>
>>> "If the CCXML browser can not represent the content in ECMAScript (for
>>> example some content that was fetched in processed mode) this may be
>>> ECMAScript undefined."
>>>
>>> This implies that for some content in processed mode this atribute can
>>> contain a representation of the fetched content. Could this be more
>>> specific? When shall the content be specified and when not in processed
>>> mode? For instance, when fetching a CCXML document in processed mode,
>>> shall a text representation be also included in the content attribute?
>
> No specific requirement one way or another when it comes to processed mode fetches. We suspect most platforms will choose not to make the raw text available in processed mode for performance reasons but if they do thats where to put it.
>
>
>>> 3) 6.3.3 error.fetch:
>>>
>>> What are content and contenttype attributes good for in this event? I
>>> can imagine that there are situations where we obtain contenttype and
>>> then content fetching fails. Regarding the content attribute, how can it
>>> be used here? The only situation I can imagine is a content that was
>>> downloaded but parsing failed (in processed mode). Is it correct?
>
> You are indeed correct.
>
>>>
>>> Please clarify on this.
>>>
>>> Furthermore, all the attributes in error.fetch are required although they are not always available. When we fail to access the document (e.g. the server is unreachable) we don't have neither content nor content type. These attributes will be undefined. Wouldn't it be better to make them optional?
>
> You are indeed correct, that they won't always have values if there was a bad fetch. An example of where they might be populated however is if a server returned a 404 but also content with error messages with more detail. We chose to map the case where there is nothing to expose as ecmascript undefined but you are right, we could have chosen to just make the attribute optional.
>
>
>
> Does this resolve your issues? If so we will go on and close out the issue in tracker.
>
> Best regards,
>
> 	RJ
>
>
> ---
> RJ Auburn
> CTO, Voxeo Corporation
> tel:+1-407-418-1800
> skype:zscgeek
>
>

Received on Friday, 17 September 2010 07:03:10 UTC