Re: Consolidated comments on CCXML from OptimSys

Petr,

Thanks for the feedback on this. We will see about reviewing this at our
next CCXML meeting.

    RJ


On 01/25/2005 09:54, "Petr Kuba" <kuba@optimsys.cz> wrote:

> 
> Dear Voice Browser Working Group,
> 
> below please find consolidated comments on the second last call CCXML
> working draft (11 January 2005) from OptimSys Ltd, Czech Republic.
> These comments are based on issues that have arisen during the
> implementation of our CCXML interpreter. They are ordered by section
> and numbered for easy reference.
> 
> We are looking forward to your responses.
> 
> Best regards,
> 
>     Petr Kuba, Senior software architect
>     OptimSys Ltd.
>     kuba@optimsys.cz
>     http://www.optimsys.cz
> 
> 
> 
> 
> PROBLEM 1: Section 8.4 missing in the Table of Contents
> Location: Table of Content
> Proposed change: Add Section 8.4 to the Table of Contents.
> 
> ---
> PROBLEM 2: Element <merge> missing in the CCXML Elements Listing
> Location: Section 5
> Proposed change: Add link to the <merge> element.
> 
> ---
> PROBLEM 3: Different values indicating missing parent session
> Location: Sections 6.3.5 and 8.3
> 
> Rationale:
> The description of the the 'parent' field of the 'ccxml.loaded' event
> in the Section 6.3.5 says: "the identifier of the session which issued
> the <createccxml> to start this document; if this document was started
> directly by the CCXML platform, the identifier is 0".
> 
> While the description of the standard session variable
> 'session.parentid' in the Section 8.3 says: "String that indicates the
> session identifier of the parent of the CCXML session that created
> this session. In the case the current session has no parent, the value
> of the variable will be ECMAScript undefined."
> 
> Both values refer to the same thing and thus should be the same.
> Moreover, the value undefined seems to be more logical than the value
> zero to indicate no parent
> 
> Proposed change: Change the zero in the section 6.3.5 to undefined
> 
> ---
> PROBLEM 4: Request for a new feature
> Location: Section 7.3
> 
> Rationale:
> Consider the following situation: The dialog environment is started
> successfully, but after some time it forcibly terminates, e.g. due to
> some internal error. CCXML definitely should handle this case somehow
> and inform the caller appropriately. To the best of our knowledge,
> there is currently no suitable event defined for this case. Therefore
> we suggest that a new event (e.g. 'error.dialog') should be defined
> for this case.
> 
> Proposed change:
> Define an additional event 'error.dialog' for indication of dialog
> errors that are not covered by more specific error.dialog.* errors.
> 
> ---
> PROBLEM 5: Typo (boject)
> Location: Section 7.4
> 
> Original:
> An instance of the Dialog boject is associated with each dialog...
> 
> Proposed change:
> An instance of the Dialog object is associated with each dialog...
> 
> ---
> PROBLEM 6: ECMAScript object property cannot be an expression
> Location: Section 7.4, description of 'type' and 'src'
> 
> Rationale:
> According to the spec, the 'type' and 'src' properties should be an
> ECMAScript expression which is not possible. This seems to be a
> cut'n'paste problem, expressions are typically used in XML attributes.
> We propose the following change:
> 
> Original:
> an ECMAScript expression which returns a character string that
> specifies the MIME type of the document that loaded the dialog.
> 
> Proposed change:
> An ECMAScript string value that specifies the MIME type of the
> document that loaded the dialog.
> 
> Original:
> Is an ECMAScript expression which returns a character string
> identifying the URI of the dialog document.
> 
> Proposed change:
> An ECMAScript string value identifying the URI of the dialog document.
> 
> ---
> PROBLEM 7: Presence of the 'src' and 'fetchid' attributes of the
> <script> element and the element content
> Location: Section 8.2.2.2
> 
> Rationale:
> The description of the 'src' attribute implies that the <script>
> element content can be present even if 'src' or 'fetchid' attribute is
> present (and the attribute takes precedence in such a case). We find
> this confusing because there can be two sources of the script content
> defined while only one will be acutally used. The 'src' attribute,
> 'fetchid' attribute and the element content should be mutually
> exclusive (similarly as in VoiceXML). We propose the following change:
> 
> Original:
> URI which references a resource which is the script content, and which
> will be resolved when the CCXML document is compiled. If both the src
> and fetchid are not present, the script element content provides the
> script content. If both are present the implementation must throw an
> error.fetch event.
> 
> Proposed change:
> URI which references a resource which is the script content, and which
> will be resolved when the CCXML document is compiled. Note that the
> src attribute, fetchid attribute and the script element content are
> mutually exclusive and exactly one of them must be present, otherwise
> the implementation must throw an error.fetch event.
> 
> ---
> PROBLEM 8: Typo (missing and)
> Location: Section 8.3, description of the standard session variable
>            'session.parentid'
> 
> Original:
> Once a new CCXML session is created, the new session its parent are
> completely independent.
> 
> Proposed change:
> Once a new CCXML session is created, the new session and its parent
> are completely independent.
> 
> ---
> PROBLEM 9: managing updates to application variables
> Location: Section 8.4
> 
> Rationale:
> The spec mentiones that it is the responsibility of the CCXML
> implementation to initialize the 'application' object and manage
> updates to application variables. It is not clear what is meant by
> "manage updates to application variables". We understand that all
> application variables are created by a CCXML application, i.e. the
> application can choose any names and assign and modify their values
> during the life-cycle of the application and the CCXML implementation
> does not influence this process in any way. We propose the following
> change:
> 
> Original:
> It is the responsibility of the CCXML implementation to properly
> initialize the application object and manage updates to application
> variables as they occur during the life-cycle of the CCXML
> application.
> 
> Proposed change:
> It is the responsibility of the CCXML implementation to properly
> initialize the application object.
> 
> ---
> PROBLEM 10: Delayed events
> Location: Sections 9.1, 9.2.3.2 and 9.2.5.1
> 
> Rationale: There are indications of how delayed events should be
> implemented in the spec. The way of implementation should not be
> defined in the spec and the behavior should be specified in the
> "should behave as if" manner.
> 
> Original in Section 9.1:
> When a delay is specified the event is delivered to the target CCXML
> session but it is not placed on to the event queue until the delay
> time has elapsed.
> 
> Proposed change in Section 9.1:
> When a delay is specified the event must be processed by the target
> CCXML session only after the delay time has elapsed.
> 
> Original in Section 9.2.3.2, the 'delay' attribute:
> The send tag will return immediately, but the event is not dispatched
> until the delay interval elapses.
> 
> Proposed change in Section 9.2.3.2, the 'delay' attribute:
> The send tag will return immediately, but the event must not be
> processed by the target CCXML session before the delay time has
> elapsed.
> 
> Original in Section 9.2.5.1:
> The cancel operation will cancel a pending event by removing it from
> the event queue of the CCXML session from which it has been sent.
> 
> Proposed change in Section 9.2.5.1:
> The cancel operation will cancel a pending event by removing it from
> the respective event queue.
> 
> 
> ---
> PROBLEM 11: Wrong paragraph order
> Location: Section 9.1
> 
> Rationale:
> The paragraph starting with "During the processing of an event..."
> mentions EHIA before it is defined.
> 
> Proposed change:
> Move this paragraph behind the paragraph starting with "Any events
> that arrive while..."
> 
> ---
> PROBLEM 12: Value of the 'eventsource' attribute
> Location: Section 9.4.2
> 
> Rationale:
> Each event must have the 'eventsource' attribute. However, it is not
> clear what the value of the 'eventsource' attribute should be in many
> cases.
> E.g.:
> - ccxml.exit, ccxml.created - is the event source the exiting/creted
> session or the platform?
> - dialog.* - is the event source the platform or the dialog?
> - send.successuful - is the event source the platform or the target
> session?
> 
> And if the event source is the platform, is the value 0 or undefined?
> (see PROBLEM 3).
> 
> Please clarify this.
> 
> ---
> PROBLEM 13: error.ccxml
> Location: Section 9.5
> 
> Rationale:
> An 'error.ccxml' event is mentioned in this section which is not
> mentioned anywhere else. We believe it is a typo and propose the
> following change:
> 
> Original:
> A CCXML interpreter MAY provide the attributelist property on the
> error.ccxml event.
> 
> Proposed change:
> A CCXML interpreter MAY provide the attributelist property on the
> error event.
> 
> Note: the word 'error' in the changed phrase is a normal word, not
> a <tt>-ed name.
> 
> ---
> PROBLEM 14: Element <merge> missing in the list of elements at the
> beggining of the section.
> Location: Section 10
> 
> Proposed change:
> Add the <merge> element to the list of elements at the beggining of
> the section.
> 
> ---
> PROBLEM 15: Unclear description of <dialogstart> and Connection
> relationship
> Location: Section 10.2
> 
> Rationale:
> Paragraph 2 says: "<dialogstart> implicitly creates a Connection and
> bridges it to another Connection or to a Conference specified as an
> attribute of <dialogstart>."
> 
> It is not clear what is meant by "implicitly creates a Connection". Is
> this implicit connection inserted into session.connections? If so,
> does it have the same id as the dialog? Or does it just mean that the
> dialog behaves like a Connection?
> 
> Please clarify this.
> 
> ---
> PROBLEM 16: non-blocking <createcall>
> Location: Section 10.5.4.1
> 
> Rationale:
> The spec explicitly states that the <createcall> element is
> non-blocking, however, it is not mentioned in the descriptions of
> other elements even if they are non-blocking as well. We find this
> confusing and propose to omit this statement.
> 
> Original:
> This element will instruct the platform to allocate a Connection and
> attempt to place an outgoing call to a specified address. The element
> is non-blocking, and the CCXML document is immediately free to perform
> other tasks, such as initiating dialog interaction with another
> caller. The CCXML interpreter will receive an asynchronous event when
> the call attempt is completed.
> 
> Proposed change:
> This element will instruct the platform to allocate a Connection and
> attempt to place an outgoing call to a specified address. The CCXML
> interpreter will receive an asynchronous event when the call attempt
> is completed.
> 
> ---
> PROBLEM 17: 'connectionid' attribute description inconsistency
> Location: Section 10.5.9.2
> 
> Rationale:
> According to the Attribute details table, the attribute 'connectionid'
> is not required. However, below the table it is stated: "A
> <disconnect> MUST specify a connectionid attribute." This sentence is
> probably obsolete.
> 
> Proposed change:
> Remove the sentence "A <disconnect> MUST specify a connectionid
> attribute."
> 
> ---
> PROBLEM 18: meaning of asterisk
> Location: Section 10.6
> 
> Rationale:
> In the description of the most of the events, there is an asterisk at
> the 'protocol', 'reason' and 'info' attributes. What does it mean?
> 
> Please clarify this.
> 
> ---
> PROBLEM 19: description of 'conference.joined', 'conference.unjoined'
> Location: Sections 10.6.13, 10.6.14
> 
> Rationale:
> The descriptions of the the 'id1' and 'id2' attributes of the <join>
> and <unjoin> tags in the Sections 10.5.7.2 and 10.5.7.2 say: "An
> ECMAScript expression which returns a string that is the identifier of
> a Connection, Dialog or Conference." Therefore "Dialog" should appear
> also in the description of 'conference.joined' and
> 'conference.unjoined' events.
> 
> Original:
> This event is emitted when two resources (which are connections
> or conferences) have been bridged using <join>.
> 
> Proposed change:
> This event is emitted when two resources (which are connections,
> dialogs or conferences) have been bridged using <join>.
> 
> Original:
> (4 occurences, in 'id1' and 'id2' descriptions of 'conference.joined'
> and 'conference.unjoined') The ID of the Connection or Conference
> representing a resource associated with this event
> 
> Proposed change:
> The ID of the Connection, Dialog or Conference representing a resource
> associated with this event
> 
> 
> 

---
RJ Auburn
CTO, Voxeo Corporation
tel:+1-407-418-1800

Received on Wednesday, 26 January 2005 15:22:11 UTC