Re: Comments on DCI

[Rafah A Hosn]

Hello Debbie

Thank you, and the MMI group, for reviewing the DCI second last call draft.
Following are a set of responses to the comments that the group has made.

(1) "We notice from section 4.1.2 that DCI access to remote device
properties is supported.  Consider the case where multiple devices are
cooperating in a single application.  If one of the devices wants to
monitor properties on all the others, will it have a single instance of the
DCI, with a separate branch for each device, or will it have multiple
instances of the DCI?  From section 4.1.6, it would appear that the former
would be the case, but we would like this to be made explicit."

Response: the DCI specification does not confine developers as to how many
instances of the DCI tree they can/should have or who should host these
instances as these are implementation dependent. One possible
implementation in a multimodal framework is to have one instance of the DCI
tree hosted by the interaction manager and have appropriate remote access
mechanisms for remote devices that need to update/montior properties in
that tree.

(2) Remote access to properties

Response: we acknowledge the need for protocols and access methods for
remote properties however we believe that this is out of scope, at least
for the first release of the DCI specification.

(3) Efficiency concerns for multiple updates

Response: again, we do acknowledge the need for efficiency mechanisms (as
mentioned in section 4.1.4) specially to alleviate the number of
events fired, for example, when a property gets updated very frequently and
an application only requires notification at certain intervals. We have
decided to leave this out of this release and have implementors decide how
best to optimize property updates and access.


Thank you again,
--- rafah

[Deborah Dahl]

Hello Rafah,

Thank you and the Device Indepence Working Group for considering
the comments from the Multimodal Interaction
Working Group [1] regarding the DCI second Last Call Working Draft. The
MMI Working Group has discussed your comments and we are satisfied
with your responses. However, in reference to point 2, we would like
to encourage you to consider remote access in more detail in future
versions of the DCI specification.

Best Regards,

Debbie Dahl
Chair, Multimodal Interaction Working Group

[1] http://lists.w3.org/Archives/Public/www-di/2005Dec/0002.html

> -----Original Message-----
> From: w3c-mmi-wg-request@...
> [mailto:w3c-mmi-wg-request@...] On Behalf Of Rafah A Hosn
> Sent: Friday, January 06, 2006 10:21 AM
> To: www-di@...; w3c-mmi-wg@...
> Subject: Re: Comments on DCI
>
>
>
> Hello Debbie
>
> Thank you, and the MMI group, for reviewing the DCI second
> last call draft.
> Following are a set of responses to the comments that the
> group has made.
>
> (1) "We notice from section 4.1.2 that DCI access to remote device
> properties is supported.  Consider the case where multiple devices are
> cooperating in a single application.  If one of the devices wants to
> monitor properties on all the others, will it have a single
> instance of the
> DCI, with a separate branch for each device, or will it have multiple
> instances of the DCI?  From section 4.1.6, it would appear
> that the former
> would be the case, but we would like this to be made explicit."
>
> Response: the DCI specification does not confine developers
> as to how many
> instances of the DCI tree they can/should have or who should
> host these
> instances as these are implementation dependent. One possible
> implementation in a multimodal framework is to have one
> instance of the DCI
> tree hosted by the interaction manager and have appropriate
> remote access
> mechanisms for remote devices that need to update/montior
> properties in
> that tree.
>
> (2) Remote access to properties
>
> Response: we acknowledge the need for protocols and access methods for
> remote properties however we believe that this is out of
> scope, at least
> for the first release of the DCI specification.
>
> (3) Efficiency concerns for multiple updates
>
> Response: again, we do acknowledge the need for efficiency
> mechanisms (as
> mentioned in section 4.1.4) specially to alleviate the number of
> events fired, for example, when a property gets updated very
> frequently and
> an application only requires notification at certain
> intervals. We have
> decided to leave this out of this release and have
> implementors decide how
> best to optimize property updates and access.
>
>
> Thank you again,
> --- rafah
>
>
>