Looks good.

Regards,
Chris

Baggia Paolo wrote:
Chris,

We are in the process to address all ISSUES related to IR. The goal is to re-publish the CCXML-IR in a short term.
Please explicitly confirm that you accept the proposed resolution or after one week we will consider implicitly accepted the resolution. If you need clarification, please ask them very soon.

Paolo Baggia
Author of CCXML-IR Plan

ISSUE-672:

Proposed Resolution: Accept

You are right on both the issues:
- Wrong examples in Spec with dialogid on connections and connectionid on dialogs
  They will be fixed in next publication by carefully checking the whole spec
- We will recheck all the test case to fix related errors
- #287 has to be rejected because the text is obsolete

=================================
Chris,

This issue is tracked as ISSUE-672. 

This may indeed be a leftover from the changes we made to fix the input/outputs cases. We will review on the next working group call and let you know what we think. 

	RJ

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

On Apr 12, 2010, at 4:47 PM, Chris Davis wrote:

  
Hello www-voice,

dialogid shows up as a property of the Connection class in assertion #287,
but is not listed under http://www.w3.org/TR/2010/CR-ccxml-20100401/#connection.properties

The implementation report text for #287 (http://www.w3.org/Voice/2009/ccxml-irp/ )
uses for justification the text:
   "A Connection Object may have a dialogid property which
   is the identifier of an associated dialog, if there is one currently using the connection."

and then links back to the table of connection properties in an attempt to justify the
made-up rule.

We don't think this is a simple case of dialogid having been accidentally left off the
Connection property table. A Connection can have more than one media input and/or Dialog
associated with it at any one time. This is a purpose of the input and outputs properties
of the Connection class. This alone would seem to defeat a single dialogid property.

For example, consider a call flow where there are 2 simultaneous recordings to different
files from a single Connection.
These could have been launched via <dialogstart mediadirection="'dialogreceive'"/>.
In this case, which dialogid would be "associated" with the single Connection class?
The single dialogid property would then be a bogus indication of what is associated with the Connection.

It seems that to have a dialogid property associated with the Connection class ignores
the one to many relationship that CCXML says it supports. The problem extends beyond the
test cases, as some examples in the CCXML Recommendation list *imply* dialogid as a property of the Connection
class (7.1, 7.2.1.1, 10.4.2, maybe others).
We recommend striking the examples from the Recommendation, and altering any test cases
that imply a one-to-one relationship. In 10_2_2_A.txml, we changed:
   <if cond="session.connections[OutboundID4].dialogid == DialogID">
to be instead:
  <if cond="session.connections[OutboundID4].input == DialogID &amp;&amp; session.connections[OutboundID4].outputs[0] == DialogID">

Thanks,
Chris

-- 
Chris Davis
Interact Incorporated R&D
512-502-9969x117
    


  


-- 
Chris Davis
Interact Incorporated R&D
512-502-9969x117