Feedback on CCMXL LCWD2 from the Multimodal Interaction Working Group

Dear Voice Browser Working Group,

The Multimodal Interaction Working Group has reviewed the 
CCXML Last Call Working Draft [1] in response to the WG's request 
and has prepared the following feedback. 
Thanks to Raj Tumuluri for preparing the feedback.
(Note that this is the same feedback that was originally sent to
the Voice Browser WG's group mailing list. We are resending it
to this list to make it publicly available.)

best regards,

Debbie Dahl, MMI WG Chair

[1] http://www.w3.org/TR/2005/WD-ccxml-20050111/


Feedback from MMI-WG on CCXML LCWD2
- Raj Tumuluri
----------------------------------------------------------------
I) Takeaway for MMI-WG:
 
- designed to complement dialog systems such as VoiceXML by providing
advanced 
  (telephony )call-control /conferencing functions
 
- CCXML and VoiceXML implementations are not mutually dependent
  ( CCXML can support other dialog languages/technologies like SALT)
 
- Relevance to MMI: potential candidate for Container/Interaction
Manager(IM) language for
  implementation 
  
II) Summary:
 
- language model supports: 
    * Document Control: These events are detailed in section 6.3
    * Dialog Control: These events are detailed in section 7.3
    * Event Handling Control: These events are detailed in section 9.3
    * Call Control: These events are detailed in section 10
 
and elements support asynchronous communication
 
- language semantics based on the ECMAScript Compact Profile (ES-CP, also
known as ECMA-327) [ECMA327]
  ( stated goal: execution efficiency )
 
- "intended to be used in large, real-time telephony platforms managing
thousands of lines" 
   and not really targeted towards "battery-powered-embedded systems"
 
-  Implementation MAY support interaction with several dialog systems with
the selection of the particular  
 
 technology being based on the MIME type specified when the dialog is
initiated
 
-  The output of a Connection or Conference can be directed to the inputs of
one or more Connections and/or Conferences ( splitting of media streams)and
platform MUST support these type of bridges.
 
-  A Connection or Conference input can come from the output of only one
Connection or Conference.
  ( two modes can be conferenced to give input to the bigger Conference
Object a la russian-doll model in IM )
 
- Events are queued FIFO ( except for Kill etc.. )
 
  ( EHIA similar to FIA )
  
Session management : 
- concurrent independent execution of CCXML and VoiceXML applications (the
CCXML and VoiceXML cookie stores are independent)
-Authors wishing to correlate CCXML and VoiceXML data at the server can use
URL rewriting or alternatively employ the CCXML sessionid variable together
with the connectionid or conferenceid as a common, unique key across the
CCXML and VoiceXML applications
 
- possible to transfer execution-context to a different session (to other
modality component)
 
III) Questions:
 
1. Given the media-stream/dialog-system independence, should the scope be
limited
   to just telephony-call-control?
 
2. Not clear on how authors can query the host-environment to get the
information on whether
  or not other dialog-systems ( modailty components for us) that may have
been implemented
 
3. Need well-defined Dynamic Profile Framework (DPF) / System & Environment
(S&E) interfaces 
 
4. Section 3.2 - conference technology is implementation dependent, and
CCXML implementation may not support all conference features. Is there any
mechanism for remote application to discover which service it supports?
 
5. CCXML provides one  particular call control model and service
environment, allowing a flexible integration with voice dialogue systems.
But there are other call control models that can support the need of
VoiceXML. This picture should be made clear.
 
6. Variable scope seems unclear: In section 8.4 the language seems to
suggest that "CCXML implmentation is responsible to properly initialize the
application object and manage updates to application variables as they occur
during the life-cycle of the CCXML application". While the
CCXML-implementation is responsible for initialization of the application
object and its variables, managing those values during the life-cycle  is
certainly in the application domain and therefore should not be the
responsibility of the CCXML-implementation. 
 
--
 
Raj Tumuluri
 
Phone : +1 (732) 417 1683
Fax :     +1 (732) 417 1295
Email: raj@openstream.com
Openstream Inc
 
Making Communication Smarter!
www.openstream.com
 
Vision without execution is Hallucination.......

Received on Monday, 28 March 2005 15:41:53 UTC