W3C home > Mailing lists > Public > www-voice@w3.org > January to March 2005

Feedback on CCMXL LCWD2 from the Multimodal Interaction Working Group

From: Deborah Dahl <dahl@conversational-technologies.com>
Date: Mon, 28 Mar 2005 10:41:05 -0500
To: <www-voice@w3.org>
Message-ID: <00c201c533ac$91a79e40$3a7ba8c0@chimaera>

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
  (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
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
-  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
   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!
Vision without execution is Hallucination....... 
Received on Monday, 28 March 2005 15:41:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:03:50 UTC