W3C home > Mailing lists > Public > public-dcci-editors@w3.org > December 2007

RE: LCWD comments on the DCCI specification from the Multimodal Interaction WG

From: Dave Raggett <dsr@w3.org>
Date: Fri, 7 Dec 2007 09:37:10 +0000 (GMT)
To: Deborah Dahl <dahl@conversational-technologies.com>
Cc: public-dcci-editors@w3.org
Message-ID: <alpine.DEB.0.99.0712070929180.6471@ivy>

Hi Debbie,

I think the working group decision on LC-1918 could do with a little 
clarification. This is something that we discussed together with the 
MMI WG at the recent Tech Plenary and where our explanation was 
accepted.

The DCCI is essentially a client-side interface to the delivery 
context. The OMA DCAP group are developing a server-side API for 
dynamic properties together an optimised protocol for event transfer 
in mobile networks. The W3C DDWG is defining a server-side API for 
static properties of classes (not instances) of mobile devices. Rhys 
Lewis has a diagram showing the relationships between all of these 
and has an action to add it to the UWA wiki.

The W3C UWA WG has separate chartered work items on binding to local
and remote resources, together with the means for enabling remote
eventing, but these are separate from the DCCI specification and
will take longer to progress along the REC track. We will continue
to liaise with the MMI WG as that work proceeds.

Deborah Dahl wrote on Mon, 12 Nov 2007:

> Hi Keith,
> Thank you very much for your response to our comments on the LCWD 
> of the DCCI specification. After discussing these with the UWA WG 
> at the Boston Technical Plenary, we agree that these responses 
> address our concerns. However, with respect to point 1.2, because 
> distributed applications are very important to the MMIWG, we would 
> be very grateful for any additional information you might be able 
> to provide related to your comment, "There is the potential that 
> other remote event standards could be applied to DCCI events in 
> the future."
>
> Best regards, and looking forward to continued future 
> collaboration,
>
> Debbie Dahl, MMIWG Chair, for the MMIWG
>
> > -----Original Message-----
> > From: waters Keith [mailto:keith.waters@orange-ftgroup.com]
> > Sent: Friday, October 19, 2007 3:04 PM
> > To: public-dcci-editors@w3.org; w3c-mmi-wg@w3.org; member-uwa@w3c.org
> > Cc: Deborah Dahl
> > Subject: LCWD comments on the DCCI specification from the
> > Multimodal Interaction WG
> >
> > Hi Debbie and Raj,
> >
> > thank you for your comments [1] on the LCWD of DCCI draft 04 
> > July 2007 [2].
> >
> > What follows is a breakdown set of responses:
> >
> > -------------------------------
> > 1. Registration for events:
> >
> > 1.1 Notification of Events ( Section 1.1 Uses for DCI ):
> >
> > "...It also provides notifications when properties change.."
> >
> > While the specification describes use of DOM3 events, given that 
> > DCCI will have a different root-element ( namespace), it is not 
> > clear how components that want the notifications register for 
> > the same..
> >
> > -------------------------------
> >
> > RESPONSE: The registration for events is performed on the DCCI 
> > node, with addEventListener() or addEventListenerNS().  The 
> > namespace of the event itself for the dci-prop-change event is 
> > to be http://www.w3.org/2007/dci per 
> > http://www.w3.org/TR/DPF#event-dci-prop-change and 
> > http://www.w3.org/TR/DPF#sec-conformance.  The changed DCCI node 
> > will be the target of the event, and has its own namespace. 
> > This is unrelated to any namespace associated with the 
> > registering source.
> >
> > -------------------------------
> >
> > 1.2 MMI Architecture allows Interaction Manager (IM) and 
> > Modality Components( MC) to be distributed. And except in the 
> > case of nested-modality components, modality components 
> > communicate with each other only through the Interaction 
> > Manager. Given this principle of MMI architecture, MMI authors 
> > would be required under the proposed DCCI spec, to implement 
> > another DCCI-interface component to register and obtain the 
> > local DCI events to pass on to IM for every device on which any 
> > modality component is running..
> >
> > For example, a device-client could be getting the text-to-speech 
> > streamed from a TTS server. Now, if the user mutes the speaker 
> > on the device, an event gets generated on the local device 
> > through DCI, but the IM running on the server (a different 
> > device) will not get this event to signal the TTS-component to 
> > stop streaming audio, as it will not have a way to remotely 
> > register and get this event from the device. So, under the 
> > proposed specification, an MMI author would be forced to 
> > implement another MMI component just for passing on DCI events 
> > to the IM. Please, note that the local Modality Component cannot 
> > directly do this job, as the local Modality Components are to be 
> > implemented as black-boxes and as such cannot snoop on these 
> > events and determine which ones should be passed-on to the 
> > Interaction Manager.
> >
> > We would like to hear from DCI-WG on how this 
> > remote-registration for events could be done, under the the 
> > current DCI framework.
> >
> > -------------------------------
> >
> > RESPONSE: There is no facility in place for remote event 
> > registration associated with DCCI and is therefore this is 
> > considered out-of-scope for DCCI at this time. There is the 
> > potential that other remote event standards could be applied to 
> > DCCI events in the future.  At that time DCCI can review 
> > adherence to that specification.
> >
> > -------------------------------
> >
> > 2. Section 2.1 of DCCI specification on Interfaces :
> >
> > "....DCCI is an interface that focuses on making properties from 
> > the delivery context available to code executing within a web 
> > client [GLOSS]...
> >
> > The glossary referenced above DOES NOT contain definition of 
> > web-client, but client as described below :
> >
> > Client ( www.w3.org/TR/di-gloss)
> >      The role adopted by an application when it is retrieving 
> > and/or rendering resources or resource manifestations.
> >      This term was taken verbatim from Web Characterization
> > Terminology
> > & Definitions Sheet.
> >
> > Further, from MMI perspective clients needs not be web-clients (
> > meaning implementing HTTP protocol for communication with servers..)
> >
> > -------------------------------
> >
> > RESPONSE: Thanks. There is a editorial correction to be made 
> > here. The reference to "web client" and "web server" in section 
> > 2.1 should be changed to "client" and "server".
> >
> > -------------------------------
> >
> > Hopefully this address your concerns.  If not, please respond by 
> > Nov 9th.
> >
> > Cheers,
> >
> > -Keith Waters
> >
> > [1] http://lists.w3.org/Archives/Public/public-dcci-editors/2007Aug/0000.html
> > [2] http://www.w3.org/TR/DPF/

  Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett
Received on Friday, 7 December 2007 09:36:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:11:03 GMT