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

Re: Comments on the CCXML WD of 29 June 2005

From: RJ Auburn <rj@voxeo.com>
Date: Thu, 4 Aug 2005 06:36:25 -0400
Message-Id: <FCDC17EA-7826-4B18-A6DC-DB7FDEBA6B73@voxeo.com>
Cc: <www-voice@w3.org>
To: Brian Frasca <frasca@tellme.com>

Brian,

Thank you for the additional comments on the CCXML specification.  
These have been added to your prior list of comments for review.

Thanks again,

     RJ

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



On Aug 2, 2005, at 14:01 PM, Brian Frasca wrote:

>
> Voice Browser Working Group,
>
> After reading sections 8-10 again in more detail, I've come up with  
> some
> additional comments/questions.  I know it is past the comment deadline
> but any insights you can provide on the questions below will be
> appreciated.
>
> I started numbering the new comments after the old comments so that  
> it's
> easy to uniquely identify a comment.  I've also included what I  
> believe
> to be the answer to one of my previous questions.
>
> Thanks for your efforts,
>
> Brian Frasca
> Tellme Networks
> frasca@tellme.com
>
> ----------------------------------------
> Updates on previous comments/questions
> ----------------------------------------
>
> 27.  Section 8.2.2.2.  The type for the timeout, maxage, maxstale, and
> charset attributes of <script> is "Character string".  Should the type
> be "ECMAScript Expression" instead?  Other elements such as
> <dialogstart> allow the timeout, maxage, and maxstale attributes to be
> expressions.
>
> ->  I think I understand this now.  Using "Character string" seems  
> fine
> since those attributes are only used in conjunction with the "src"
> attribute which permits compile-time script loading.
>
> However, it might be useful to be more explicit about the three
> different ways in which <script> can access executable content: (1)
> compile-time fetch with "src", (2) run-time fetch with "fetchid", and
> (3) no fetch with inline content.  It took me a couple passed before I
> understood this.
>
> ----------------------------------------
> New comments/questions
> ----------------------------------------
>
> 36.  Section 8.2.1.1 contains a reference to "section 3.4.2" which
> doesn't exist.  This should read "section 3.4" instead.  Note that the
> link itself is fine -- just the text is wrong.
>
> ----------------------------------------
>
> 37.  In section 8.2.1.1, the table that describes the scopes says that
> attempts to assign to an existing session variable will be  
> ignored.  Why
> not throw an error.semantic here instead?  Clearly the application is
> doing something wrong if it attempts to assign to a session variable.
> Hiding the error from the application doesn't seem like the best
> decision.
>
> ----------------------------------------
>
> 38.  In section 8.4, the last sentence starts with "Application
> developer should..." but "developer" should be plural ("developers").
>
> ----------------------------------------
>
> 39.  In section 9.1, the first sentence of the third paragraph has a
> parenthetical expression with a period in it.  This is slightly
> confusing as it makes the first sentence appear to end before it  
> really
> has.
>
> ----------------------------------------
>
> 40.  In section 9.1, the ninth paragraph describes the criteria for
> selecting a transition as the event type and optional condition but  
> does
> not mention the optional state.
>
> ----------------------------------------
>
> 41.  Section 9.2.2.  Is there a specific order in which the attributes
> of a <transition> element must be processed?  For example, if the  
> event
> attribute of a <transition> doesn't match will the expression for the
> cond attribute still be evaluated or can an implementation
> "short-circuit" to skip this evaluation?  If the evaluation order or
> short-circuit behavior isn't well defined then side effects in
> expressions could result in different behavior on different platforms.
>
> In general, side-effects in expressions in attributes can cause  
> platform
> specific behavior for any element that has more than one expression
> attribute (e.g. <fetch> has eight expression attributes).  I guess  
> this
> will be pretty rare so perhaps it's sufficient to leave this behavior
> platform specific and warn users against side-effects.
>
> ----------------------------------------
>
> 42.  Section 9.2.3.  If an event using the data/namelist attributes is
> sent to a CCXML session or dialog, is the mapping from event data (in
> the namelist attribute) to event object properties specified by the
> CCXML standard?
>
> Based on examples from other events like ccxml.exit and dialog.exit I
> would guess that the data is supposed to be stored under  
> "evt.values.*"
> where "evt" is the name of the event object.  However, based on the
> examples in 9.2.3.3, it looks like the data is supposed to be stored
> directly under evt like "evt.jacksvar".
>
> Also, are qualified variable names allowed in the namelist  
> attribute of
> <send>?  If so, would namelist="jacksvar.foo" get mapped to
> "evt.jacksvar.foo"?  Or, perhaps, should the mapping be similar to
> ccxml.exit and dialog.exit where "evt.namelist.*" and "evt.values.*"
> contain the names of custom properties and their values?  And, if this
> is the case, would the variable names be restricted to unqualified?
>
> Of course, if an HTTP event processor is used then supporting  
> qualified
> variable names makes sense just as it does for <fetch>, <createccxml>,
> <dialogprepare>, and <dialogstart>.  Note that the description for the
> namelist attribute in 9.2.3.2 includes the "date.month date.year"
> example which implies that qualified variable names are permitted.
> However, unlike the descriptions for the namelist attribute for  
> <fetch>
> et. al., it is not explicitly stated that qualified variable names are
> permitted.
>
> ----------------------------------------
>
> 43.  Section 9.2.3.2.  The description for the data and namelist
> attributes of the <send> element say that an error.fetch event will be
> thrown if the those attributes are used in conjunction with inline
> content or if neither the data attribute nor inline content is  
> included.
> Should an error.send.failed event be thrown instead?
>
> ----------------------------------------
>
> 44.  In section 9.2.4.1, the first paragraph says that an error.fetch
> event will be thrown if neither or both the event and source  
> attributes
> are specified on <move>.  It seems like an error.move event would be
> more appropriate.  In general, it seems like there are lots of cases
> where error.fetch is thrown but other more specific events seem more
> appropriate.  Are these error.fetch events specified by mistake?
>
> ----------------------------------------
>
> 45.  The table in section 9.4.2.2 shows four standard event properties
> including "eventid".  Is the "eventid" property really present for all
> events?  The other three properties (name, eventsource, and
> eventsourcetype) appear in the property list tables for all events but
> the eventid property doesn't appear for any events.
>
> Also, the table in section 9.4.5.1 says that error events include name
> and reason as common properties.  Are these common properties in
> addition to the standard ones in 9.4.2.2 or in place of them?  If they
> are in addition to the standard fields then the name property should
> probably be removed since it already appears in the standard list.  If
> it is instead of the standard fields then it's interesting to note  
> that
> even the error events have explicitly listed eventsource and
> eventsourcetype as properties.  Should they?
>
> Similarly, the table in section 10.2.3 showing common connection event
> properties only includes eventsource and eventsourcetype both of which
> are also "standard" event properties.  However, this table does not
> include the name property which I believe is also always present for
> connection events.
>
> ----------------------------------------
>
> 46.  In section 10.2.1, the diagram shows a <disconnect> transition  
> from
> the PROGRESSING state to the FAILED state but the table does not show
> this transition.  Note that, as mentioned in comment #29 before, the
> connection.signal transition is also missing in the table for this
> state.
>
> Also, the table shows a <redirect> transition from the PROGRESSING  
> state
> to the FAILED state that the diagram does not.  Is this one of the  
> cases
> that was omitted for clarity?
>
> Most importantly, we were expecting there to be a <merge> transition
> from the PROGRESSING state to the DISCONNECTED state but it does not
> appear in either the diagram or the table.  We assume that a
> "supervised" transfer would be done through this transition:  (1) an
> inbound call is accepted and connected to a dialog where the caller
> requests a transfer; (2) an outbound call is placed to the transfer
> target; and (3) while the outbound call is in the PROGRESSING state
> (i.e. ringing), the inbound and outbound calls are merged (via  
> <merge>)
> and the inbound caller hears the ringing of the outbound callee's  
> phone.
>
> Lastly, we were unable to think of a scenerio where a <merge>  
> transition
> from the ALERTING state to the DISCONNECTED state made sense.  Should
> this transition start from the PROGRESSING state instead as described
> above?
>
> ----------------------------------------
>
> 47.  In section 10.2.2, it notes that the endpoint property of a
> connection object can be a conferenceid, connectionid or dialogid.  Is
> there any way to determine which type of id is stored in this  
> property?
> If you want to use this value to index into one of the session.*  
> arrays,
> for example, then you need to know the type.
>
> Similarly, certain events such as conference.joined and
> conference.unjoined contain properties that can be ids for different
> types of objects.  Is there any way to determine the object type in
> those cases?
>
> ----------------------------------------
>
> 48.  In the table in section 10.2.2, the definitions of the local and
> remote conection properties end in semi-colons but should probably end
> in periods.
>
> ----------------------------------------
>
> 49.  Section 10.3 says that a session may establish a bridge to a
> conference without having executed a <createconference>.  If this
> happens, will the session implicitly hold a reference to the  
> conference?
> And if so, how will that reference be released?  Based on other  
> sections
> like 10.5.6.1, I'm guessing that in this case a session won't hold a
> reference to the conference for the purpose of <destroyconference>
> reference counting.
>
> Also, if an implicit reference like this is setup between a session  
> and
> a conference will the conference appear in the session's
> session.conference array?  Similarly, will the session receive
> conference.joined and conference.unjoined events from other sessions
> that join/unjoin to the conference?  I'm guessing that these last two
> questions are linked and that the answer to both is "yes".
>
> In any case, it might be worth describing the behavior a little more
> explicitly.
>
> ----------------------------------------
>
> 50.  Section 10.3 mentions that conferences are global across all
> sessions.  Does this mean that the session.conferences array for a  
> given
> session should include all conferences for all sessions?  Or should it
> just include the conferences for which the given session holds a
> reference?  I presume that the latter is correct.
>
> ----------------------------------------
>
> 51.  Section 10.4 says, "A Connection or Conference input can come  
> from
> the output of only one Connection or Conference."  Isn't this only  
> true
> for a connection?  Can't a conference input come from multiple
> connection/conference outputs?
>
> ----------------------------------------
>
> 52.  In section 10.4, the last sentence in the paragraph talking about
> "hot word" recognition ends in a colon.  It looks like the last WD
> included an italicized rule after the colon.  Should that be added  
> back?
>
> ----------------------------------------
>
> 53.  In section 10.4.2, the <dialogstart> example includes a "duplex"
> attribute.  Instead of duplex="'full'" should this be
> mediadirection="'both'"?
>
> ----------------------------------------
>
> 54.  In section 10.5.4.2, the description of the joindirection  
> attribute
> for <createcall> uses dialogreceive but should use callreceive.  Note
> that the correct value is present in the "Valid Values" column -- it's
> just the "Description" column that is wrong.
>
> ----------------------------------------
>
> 55.  Section 10.5.6.1.  If the execution of <destroyconference>
> successfully decrements the reference count but does not deallocate  
> the
> conference object (due to other references) will it generate a
> conference.destroyed event?  Looking forward, this is clearly the case
> reading section 10.6.12, however, the last sentence of the first
> paragraph in section 10.5.6.1 implies that perhaps an
> error.conference.destroy event might be thrown instead.
>
> Also, if a session executes <destroyconference> when it still has  
> active
> connections joined to that conference what happens?  I presume that  
> this
> should behave as if the session first <unjoin>ed all joined  
> connections
> which in turn would result in conference.unjoined events being sent to
> all other sessions referencing the conference.  If so, perhaps this
> should be mentioned explicitly in section 10.5.6.1.
>
> Finally, is there any way for a session that executes
> <destroyconference> to determine if the conference was actually
> destroyed as opposed to the reference count just being decremented?  I
> don't have a specific use case that requires this but I wouldn't be
> surprised if such a use case surfaces at some point.  For example,
> perhaps someone will have a need to perform some application specific
> handling (such as extra cleanup or sending a special message to  
> another
> system) only after the "real" destruction of the conference occurs.
>
> ----------------------------------------
>
> 56.  In section 10.5.9.1, the second paragraph mentioned that
> conference.unjoined must be sent to the document if the disconnected
> connection was bridged.  I assume that if the disconnected connection
> was bridged to a conference then a conference.unjoined event must be
> sent to each session that references the conference -- not just the
> session that issued the <disconnect>, right?
>
> ----------------------------------------
>
> 57.  Section 10.6.13.  Are the values of id1 and id2 in the
> conference.joined event guaranteed to be in the same order as the
> corresponding <join>?  What is the order of the ids if the event is
> generated due to a <createcall> with joinid?  Will the id of the new
> call be in id1?  For ease of application programming, it seems like  
> it's
> worthwhile making the order of the ids explicit.
>
> Same comment for conference.unjoined in section 10.6.14,
> error.conference.join in section 10.6.17, error.conference.unjoin in
> section 10.6.18.
>
> ----------------------------------------
>
> 58.  In section 10.6.19, the first sentence ends with two periods.
>
> ----------------------------------------
>
>
>
Received on Thursday, 4 August 2005 10:36:48 GMT

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