W3C home > Mailing lists > Public > www-voice@w3.org > July to September 2005

Re: Consolidated comments on CCXML (WD 29 June 2005) from OptimSys

From: RJ Auburn <rj@voxeo.com>
Date: Sat, 30 Jul 2005 17:34:18 -0400
Message-Id: <909E0ED7-181E-479F-86C3-9BC566EE330C@voxeo.com>
Cc: www-voice@w3.org
To: Petr Kuba <kuba@optimsys.cz>

Petr,

Thank you for sending these comments out. The working group will  
review these on an upcoming teleconference and report back the  
results of the review.

Thanks again,

     RJ

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



On Jul 26, 2005, at 6:28 AM, Petr Kuba wrote:

>
> Dear Voice Browser Working Group,
>
> below please find consolidated comments on the third last call CCXML
> working draft (29 June 2005) from OptimSys Ltd, Czech Republic.
> The comments are ordered by section
> and numbered for easy reference.
>
> We are glad to say that the third last call CCXML working draft has  
> clarified many issues. We appreciate your hard work.
>
> We are looking forward to your responses.
>
> Best regards,
>
>    Petr Kuba, Senior software architect
>    OptimSys Ltd.
>    kuba@optimsys.cz
>    http://www.optimsys.cz
>
>
> ===================================================================
>
> First, we would like to repeat a couple of our comments on the  
> previous working draft that have been neither reflected in the last  
> version nor (explicitly) rejected.
>
> ---
> PROBLEM 1 (previous 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 2 (previous PROBLEM 28): Unclear attribute value
> Location: 6.2.7.2
>
> Rationale:
> In the Attribute Details table of the <fetch> tag, the following valid
> values are shown for the 'type' attribute: 'application/ccxml+xml',
> 'text/ecmascript', and 'text/javascript'. We do not understand when
> the 'text/javascript' value could appear and what it should be used
> for. Is the interpretation of this value equal to he 'text/ecmascript'
> value?
>
> Please, clarify this.
>
> ---
> PROBLEM 3 (previous PROBLEM 32): Use <dialogterminate> tag instead of
> 'connection.disconnect.hangup' event
> Location: Appendix D
>
> Rationale:
> The Second Last Working Draft of CCXML uses <dialogterminate> tag
> instead of sending 'connection.disconnect.hangup' event directly in
> the VoiceXML <disconnect> description. However, in the VoiceXML
> <transfer> description, a 'connection.disconnect.hangup' event is used
> directly. We believe that a <dialogterminate> should be used in this
> case as well.
>
> Proposed change:
> Use the <dialogterminate> tag in the VoiceXML <transfer> example
> instead of sending 'connection.disconnect.hangup' event directly.
>
> ====================================================================== 
> =
>
> Now, our new comments follow.
>
> ---
> PROBLEM 4: <log> attribute description
> Location: 6.2.11.2
>
> Rationale:
> In the description of the label attribute it is stated:
> "An ECMAScript expression which returns a character string which must
> be used, for example, to indicate the purpose of the log."
>
> In the previous version of the specification it was: "... which MAY be
> used, ..." which makes better sense.
>
> Proposed change:
> must -> may
>
> ---
> PROBLEM 5: missing attribute constrains in <dialogstart>
> Location: 7.2.2.2
>
> Rationale:
> In the previous version of the specification the following constraint
> was present for the attributes maxage, maxstale, enctype, and method:
> "This attribute may not be specified in conjunction with the
> prepareddialogid attribute."
> In the new version of the specification this constrain was removed
> from the table. We believe that the constrain makes sense and it
> should be stated.
>
> Proposed change:
> Please give the constrains back or explain why it was removed.
>
> ---
> PROBLEM 6: 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 descriptions in 9.1 and 9.2.* collide.
> According to the 9.1 the delayed events are maintained in the target
> session while according to the 9.2.3.2 and 9.2.5.1 they are stored
> locally.
>
> 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.
>
> 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.
> Note: The queue for sending events must be maintained locally. Any
> events waiting to be sent must be purged when the session that issued
> this request terminates.
>
> 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.1:
> When a delay is specified the event is not placed on to the event
> queue in the target CCXML session until the delay time has elapsed.
>
> ---
> Problem 7: optional/required marks
> Location: 10.2.3
>
> Rationale:
> In the second paragraph it is stated: "Fields marked OPTIONAL only
> appear on the event object if they have a value."
> However, the name of the table column has been changed to "Required"
> and thus the sentence should be changed analogously.
>
> Proposed change:
> "Fields not marked required only appear on the event object if they
> have a value."
>
> ---
> Problem 8: wrong media stream direction
> Location: 10.4
>
> Rationale:
> In 10.4 at the beginning of a paragraph, the following sentence is  
> stated:
> "Bridges can be either one-way, in which the media stream flows only
> from party A to party B (such that A can hear B, but B cannot hear A),
>  ..."
> The media stream direction described in the brackets is wrong, i.e. it
> does not correspond to the situation described before the bracket.
>
> Original:
> (such that A can hear B, but B cannot hear A)
>
> Proposed change:
> (such that B can hear A, but A cannot hear B)
>
> ---
> Problem 9: obsolete text
> Location: 10.4
>
> Rationale:
> In 10.4 at the end of a paragraph, the following sentence is stated:
> "This example highlights an important and subtle aspect of the
> behavior of <join> when one, or both, of the Connections being joined
> is already in one or more established bridges:"
> In the previous version of the specification this sentence was
> followed by a text that is now moved to the items above. The sentence
> does not make sense any more.
>
> Proposed change:
> remove the sentence
>
> ---
> Problem 10: illogical name of the joindirection attribute value
> Location: 10.5.4.2, description of the joindirection attribute
>
> Rationale:
> In the attribute details table of the <createcall> tag, column 'Valid'
> for the joindirection attribute shows: 'both, calltransmit,  
> callreceive'.
> However, column 'Description' describes value 'dialogreceive'. This
> seems to be a cut'n'paste problem.
>
> Original:
> dialogreceive
>
> Proposed change:
> callreceive
>
> ---
> Problem 11: connection.merged attribute name
> Location: 10.6.7
>
> Rationale:
> In the previous version of the specification the attribute name was
> 'mergedid', in the current version it is 'mergeid'.
>
> Please, could you confirm that it is not a typo?
>
> ---
> Problem 12: missing attribute 'connection' in the 'connection.signal'
> Location: 10.6.10
>
> Rationale: 'connection.signal' is the only connection.* event without
> attribute 'connection'. Since the previous version contained this
> attribute and we do not see any reason for omitting it we believe that
> this is a cut'n'paste problem.
>
> Proposed change:
> add attribute 'connection' to the 'connection.signal' event
>
> ---
> PROBLEM 13: Several typos
> We have found several typos. We list them all together here.
>
> Location: 6.2.4.1
> mustbe -> must be
>
> Location: 9.2.4.2, event attribute description
> mut->must
>
> Location: 10.5.8.1
> conferene.unjoined -> conference.unjoined
>
> Location: 11.1, error.vxml
> unavailble -> unavailable
>
>
>
>
Received on Saturday, 30 July 2005 21:34:48 GMT

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