Re: Consolidated comments on CCXML from OptimSys (2)

Petr,

Once again thanks for this feedback. We will review these comments along
with your previous ones in the working group shortly.

    RJ

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



On 01/31/2005 11:05, "Petr Kuba" <kuba@optimsys.cz> wrote:

> 
> 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 20:12:44 UTC