W3C home > Mailing lists > Public > www-voice@w3.org > January to March 2005

Consolidated comments on CCXML from OptimSys (2)

From: Petr Kuba <kuba@optimsys.cz>
Date: Mon, 31 Jan 2005 20:05:09 +0100
Message-ID: <41FE8165.1090409@optimsys.cz>
To: www-voice@w3.org

Dear Voice Browser Working Group,

as we incorporate changes specified by the new version of the CCXML
working draft into the Optimtalk CCXML interpreter, new comments on
the draft appear. Please find these comments below. The numbering of
comments continues from our previous email (25 January 2005).

Best regards,

    Petr Kuba, Senior software architect
    OptimSys Ltd.
    kuba@optimsys.cz
    http://www.optimsys.cz



PROBLEM 20: Wrong paragraph order
Location: 8.2

Rationale:
In the following paragraphs
1. "It is illegal to make an assignment to a variable..."
2. "Variables declared without an explicit initial value..."
3. "Note that when an ECMAScript object..."
the explanation of referencing undeclared variables (paragraphs 1 and 3)
is interrupted by a different topic.

Proposed solution:
Swap the paragraphs 1 and 2.

---
PROBLEM 21: Description of scopes
Location: 8.2.1.1, table with description of the scopes

Rationale:
We find the descriptions in the table unprecise and the notices about
in what scope the variables are or are not explicitly declared more
confusing then helpful. The reason is that one can create variables in
each scope without explicit declaration using the
application.varname = value; statement in a script.

We propose to state explicitly when a particular scope is created and
destroyed and whether variables can be created there only by assigning
a value to a property of the object representing the scope or also by
using <var> element or var statement within a <script>.

It is also necessary to define what happens if we assign a value to a
non-existent property of the session object. It should be considered
an error since the purpose of separate session and application scopes
is to isolate variables defined by the platform and an application.

session - original:
Variables within this scope are provided by CCXML implementation and
are read-only. They are visible to documents within the CCXML
application. See Section 8.3 for further details.

Proposed change:
This scope is opened by CCXML implementation before interpretation of
a new session starts and exists until the session exits. Variables
within this scope are provided by CCXML implementation and are
read-only. As a consequence, an attempt to assign a value to an
existing variable within this scope will be ignored. An attempt to
assign a value to a non-existent property of the session object
(session.varname = value;) causes an error.semantic event to be
thrown.

application - original:
Variables within this scope are not explicitly declared and can be
modified by CCXML programs. They are visible to documents within the
CCXML application. See Section 8.4 for further details.

Proposed change:
This scope is opened by CCXML implementation before interpretation of
a new session starts and exists until the session exits. Variables
within this scope cannot be explicitly declared using <var> element or
var statement within a <script>. They can be created only by assigning
a value to a property of the application object
(application.varname = value;). Unlike in the session scope, variables
in this scope can be modified by CCXML programs. They are visible to
documents within the CCXML application.

ccxml - original:
Variables within this scope are declared with <var> and <script>
elements that are children of <ccxml>. They are initialized in
document order when the document is loaded. They exist while the
document is loaded. They are visible only within that document.

Proposed change:
This scope is opened by CCXML implementation for each CCXML document
when it is loaded and exists while the document is loaded. Variables
within this scope are declared with <var> and <script> elements that
are children of <ccxml>. They are initialized in document order when
the document is loaded. They exist while the document is loaded. They
are visible only within that document. Variables in this scope can be
also created without an explicit declaration by assigning a value to a
property of the ccxml object (ccxml.varname = value;).

transition - original:
Each <transition> element has a scope that exists while the
implementation is processing the executable content within that
<transition>, and which is visible to the elements of that
<transition>. Variables with transition scope are declared by <var>
and <script> child elements of <transition>. The child <var> and
<script> elements of <transition> are initialized in document order
when the executable content is executed.

Proposed change:
Each <transition> element has a scope that exists while the
implementation is processing the executable content within that
<transition>, and which is visible to the elements of that
<transition>. Variables with transition scope are declared by <var>
and <script> child elements of <transition>. The child <var> and
<script> elements of <transition> are initialized in document order
when the executable content is executed. Variables in this scope can be
also created without an explicit declaration by assigning a value to a
property of the transition object (transition.varname = value;).

---
PROBLEM 22: ECMAScript session context
Location: 8.3

Rationale:
The third paragraph says: "session is a top level object inside the
ECMAScript session context." It is not completely clear what is
meant by ECMAScript session context. It is probably meant ECMAScript
execution context and its associated scope chain (as defined in
chapter 10 of ECMAScript spec) and the fact that the session object
is the top of the scope chain. We think this is quite clear from
preceding text and that the cited sentence is confusing.

Proposed change:
Omit the cited sentence.

---
PROBLEM 23: ECMAScript session context
Location: 8.4

Rationale:
The second paragraph says: "application is a top level object inside
the ECMAScript session context." It seems to be a cut'n'paste typo.
Otherwise, the same rationale applies as in the previous problem.

Proposed change:
Omit the cited sentence.

---
PROBLEM 24: Destroying Connection Objects automatically.
Location: Section 10.2.1

Rationale:
Connection Object is destroyed after it has reached the DISCONNECTED,
FAILED or ERROR states. Platforms must maintain a Connection Object
through the <transition> for the corresponding event. The document
lists these events but it misses connection.redirected and
connection.merged, which cause transition to the given states.

Original:
Platforms are responsible for deciding when to remove unused Connection
Objects, however platforms MUST maintain a Connection Object at least
through the <transition> for the corresponding connection.disconnected,
connection.failed or error.connection event.

Proposed change:
Platforms are responsible for deciding when to remove unused Connection
Objects, however platforms MUST maintain a Connection Object at least
through the <transition> for the corresponding connection.disconnected,
connection.failed, connection.redirected, connection.merged or
error.connection event.

---
PROBLEM 25: Wrong event value in the "Transitions from CONNECTED" table
Location: 10.2.1

Rationale:
In the first row of the "Transitions from CONNECTED" table (for the
Action value "connection.disconnected") the value of the Event column
should be "connection.disconnected". It seems to be a kind of
cut'n'paste typo.

Original:
connection.progressing

Proposed change:
connection.disconnected

---
PROBLEM 26: Missing description of transitions for error.merge event
Location: 10.2.1

Rationale:
The event error.merge is not listed anywhere in the tables of
transitions. Please specify transitions for this event. If
Connection transitions to the ERROR states due to this event then
PROBLEM 24 applies to it.

---
PROBLEM 27: <merge> and 'error.merge' attribute/field names
Location: 10.5.10.3, 10.6.19

Rationale:
CCXML tags should have the same attribute names if they represent the
same information. Since attributes 'id1' and 'id2' are used everywhere
(e.g. <join> and <unjoin> tags) we think that the same names should be
used in the <merge> tag and 'error.merge' event.

Original attribute/field names:
connectionid1, connectionid2

Proposed change:
id1, id2
Received on Monday, 31 January 2005 19:05:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 30 October 2006 12:49:00 GMT