This document is the Disposition of Comments for the third Last Call of
Delivery Context: Client Interface (DCCI) 1.0.
In the table below, red is in the WG decision column indicates that the Working Group didn't agree with the comment, green
indicates that a it agreed with it, and yellow
reflects an in-between situation.
In the "Commentor reply" column, red indicates the commenter objected to the WG resolution, green indicates
approval, and yellow means the commenter didn't respond to the request for
feedback.
| Commentor |
Comment |
Working Group decision |
Commentor reply |
| LC-1917
Debbie Dahl
on behalf of MMI WG (archived
comment) |
-Registration for events:
-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..
|
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/dcci 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. |
yes |
| LC-1918
Debbie Dahl
on behalf of MMI WG (archived
comment) |
Registration for events:
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.
|
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 with 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.
The W3C UWA WG has separate chartered work items on binding to
local and remote resources, together with the means for enabling
remoteeventing, 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.
The WG provided 1
answer to the commenter and 1
clarification.
|
yes |
| LC-1919
Debbie Dahl
on behalf of MMI WG (archived
comment) |
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..)
|
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". |
yes |
| LC-1785
Yi JongPil (aka JP) (archived
comment) |
Hi editor.
I have a comment for spec.
# miss spelling
Original
This document defines platform and language neutral programing
interfaces that provide Web applications access to a hierarchy of
dynamic properties representing device capabilities,
configurations, user preferences and environmental conditions.
Correction
This document defines platform and language neutral programming
interfaces that provide Web applications access to a hierarchy of
dynamic properties representing device capabilities,
configurations, user preferences and environmental conditions.
Best Regards.
From JP.
|
While both spellings are acceptable in normal English
usage (various on-line dictionaries show this), you are correct that
"programming" is more regularly used.
This will be corrected. |
tocheck |