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>


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 Auburn
CTO, Voxeo Corporation

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  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 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, 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, 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 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  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, 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 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 says that error events include name
> and reason as common properties.  Are these common properties in
> addition to the standard ones in 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, 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, 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  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 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
> 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, 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 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:07:38 UTC