Consolidated comments on CCXML from OptimSys

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

Received on Wednesday, 26 January 2005 05:41:32 UTC