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

Hi Dave,
I think this information is quite helpful. I believe it addresses 
our request for more information on device properties in 
distributed systems as we mentioned in our response to 
your response to our LC comments -- 
(http://lists.w3.org/Archives/Public/public-dcci-editors/2007Nov/0000.html).

(included below).

The MMI WG is looking forward to continued discussions with the UWA WG
on device properties in distributed systems.

regards,
Debbie

> -----Original Message-----
> From: Dave Raggett [mailto:dsr@w3.org] 
> Sent: Friday, December 07, 2007 4:37 AM
> To: Deborah Dahl
> Cc: public-dcci-editors@w3.org
> Subject: RE: LCWD comments on the DCCI specification from the 
> Multimodal Interaction WG
> 
> 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/2007Au
> g/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 13:58:15 UTC