RE: Comments on the CCXML WD of 29 June 2005

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 Tuesday, 2 August 2005 18:02:04 UTC