Disposition of Comments for Delivery Context: Interfaces (DCI) Accessing Static and Dynamic Properties-- Candidate Recommendation

19 October 2006

This document summarises the comments received following the publication of the second Last Call Working Draft of the DCI specification. The dispositions of comments from the first LCWD were compiled previously. Note: responses to comments were not formally sent but corresponding changes were made to the second Last Call draft. The second Last Call period was a review of the whole document and not only the differences with the first LCWD.


Table of Contents

Comments received during the second Last Call period

Claes Nilsson, Obigo

Original: http://lists.w3.org/Archives/Public/www-di/2005Dec/0000.html

Response: http://lists.w3.org/Archives/Public/www-di/2006Jan/0001.html

Acknowledgement: http://lists.w3.org/Archives/Public/www-di/2006Mar/0000

Status: Resolved

Nilsson 1:

DCI specifies a general framework for HTML pages to access device
properties. However, the tangible set of device properties to access
is not included in the DCI specification. Which are the plans for the
definition of these properties? Do you have any cooperation with other
W3C groups or with other standardization organizations? Alternatives
are for example to look at the OMA UAProf properties or to start out
from the JSR APIs and to create ECMAscript bindings.


In the introduction (http://www.w3.org/TR/DPF/#sec- introduction) we do state that "the Delivery Context Interfaces are designed to allow for properties to be defined by different organizations. For instance, the W3C Device Independence Activity [DevInd] is working on defining a set of core presentation attributes. The Open Mobile Alliance [OMA] (formerly known as the WAP Forum) has developed a set of properties for describing static characteristics of mobile phones. Device vendors are expected to define additional properties for proprietary features."

Nilsson 2:

In appendix B there are two informative use cases for DCI. However, we
would like to see more tangible use cases in order to achieve a better
understanding of the motivation for DCI and what it can be used for.

Agreed. There are no more examples in spec, but as implementations are created examples may well be published in a separate document.

Nilsson 3:

Security is important. Values can be set by scripts and there must be
functionality for access control. Should there functionality to
distinguish between any 3rd party web site and "safe" sites? Should
there be a separation of "safe" properties that can be accessed by any
site and "sensitive" properties that can be accessed only by "safe"


We will update the draft to (section 8.1) to provide a listing of exceptions that would be raised during security and access right violations. It is up to the implementation to raise those events under the appropriate conditions for the appropriate properties.

Nilsson 4:

The interpretation of the acronym DCI is inconsistent. At some places
in the specification it is said to mean "Device Context Interfaces"
and at other places it is said to mean "Delivery Context Interfaces".

Response: Thanks! We will do the necessary editorialization.

Nilsson 5:

For your information: Within the OMA BAC-UAProf working group there is
an activity called "Device Profiles Evolution" (DPE) that aims a
defining an enhanced device profiles mechanism which allows a device
to convey the dynamic capabilities to a service provider in real time,
thereby ensuring that the service provider can provide content best
suited to the capabilities of the device at that time. As this
activity deals with the problems of addressing dynamic changes of
device characteristics there may be connection points between the work
with W3C DCI and OMA DPE.


Thank you for the update, we are aware of OMA and are working with them.

Deborah Dahl, on behalf of Multimodal Interaction WG

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

Response: http://lists.w3.org/Archives/Public/www-di/2006Jan/0000.html

Acknowledgement: http://lists.w3.org/Archives/Public/www-di/2006Oct/0005.html

Status: Closed.

Dahl 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


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.

Dahl 2:

Secondly, do questions of efficiency arise with remote devices?  The
obvious way to implement a remote DCI interface is to maintain a local
copy which would be updated via update events.


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.

Dahl 3:

Could there be cases where the remote DCI interface needed less
frequent updates than one local on the device?  There will be
implementation-specific ways of handling this, but is a more general
means needed?


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 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.

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

David Baron, Mozilla

Original: http://lists.w3.org/Archives/Public/www-di/2005Nov/0001.html

Response: http://lists.w3.org/Archives/Public/www-di/2006Jun/0002.html

Acknowledgement: none received

Status: Not Acknowledged.

Baron 1:

I notice that the DCIProperty interface defined in [1] uses multiple
None of the DOM WG specs use multiple inheritance of interfaces
because, as I understand it, the DOM WG decided that avoiding multiple
inheritance was a valuable invariant to maintain.  Invariants,
including this one, are useful in keeping implementations simple.
This break with the convention can also make your interface impossible
to implement correctly in some bindings, such as those that depend on
COM or XPCOM, which was probably an important use case when the DOM WG
decided not to use multiple inheritance of interfaces.  (Those
bindings, in turn, may rely on single inheritance to simplify function
calls between languages.)
Working groups should not break the invariants established by other
groups: doing so leads the Web down a path towards higher
implementation complexity and thus lower reliability.  It also often
leads to the worst of both worlds (many interfaces give up the
advantages of multiple inheritance, while implementations still have
to deal with the extra complexity for the handful that broke the


Thank you for your comments. As per your request we have changed the IDL and all references to remove multiple inheritance from the interfaces, while adding text to indicate that when implementing DCI, they should inherit from both Node and EventTarget.

Robin Berjon, Expway

Original: http://lists.w3.org/Archives/Public/www-di/2006Sep/0000.html

Response: http://lists.w3.org/Archives/Public/www-di/2006Sep/0001.html


Status: Not Acknowledged.

Berjon 1

  - Why have the nodeValue be the string "NULL" and not simply have  
the null value as is usually the case for Nodes that don't have a  
value? This breaks some assumptions that implementations can make and  
might increase footprint for no obvious (from reading the draft) gain.

Response: yes, this is an error and it has been corrected

Berjon 2a

  - The valueType attribute is open-ended in what it can contain but  
you don't describe how vendors should name their types, which in turn  
may lead to type name clashes. You should probably recommend that  
vendors name their extensions using IRIs (this doesn't mean you have  
to use IRIs yourselves, you can claim that you are the only source  
allowed to use plain strings).

Response: We recognize the need to for metadata ontology's and datatyping and the DIWG will cover this in detail in a future specification. In addition, Section 5.1.1 the text has been modified as follows:

To avoid name clashes the values for valueType should be a URI.


 Also, why is this NULL (or null) for  

Response: DCIComponent doesn't have any of these and hence they are NULL.


  - Same comments for propertyType and DCIMetaDataInterfaceType (for  
the latter, unless it is always a media type, in which case this  
should be specified).

Response: this cannot be done because DCI implementation cannot know what the metadata structure is.

  - While the "any" type *might* make sense for a value since it  
could be a simple value (e.g. an int) just as well as an object, is  
that the case for DCIMetaDataInterface? Wouldn't it always something  
more structured than a simple value, say at least a string?

Response: This cannot be done because DCI implementation cannot know what the metadata structure is.


  - *Please* don't use null to indicate a wildcard for namespaceURI  
or propertyName. This is different from the way the DOM does it, and  
can cause confusion as to what describes properties in no namespace.  
Use the star instead ('*') as the other specificiations do.

Response: comment accepted and error corrected.


  - Is there really a need to have both searchProperty and  
hasProperty when they are so close? Experience shows that as soon as  
you add a convenience method to an API, users will clamour for a  
zillion others such as searchForDogFoodProperty and  
getAnArmForAHandProperty. If convenience methods are needed, they are  
best introduced in a second version based on experience from what  
users find difficult to do (or what is inefficient to implement), as  
for instance DOM 3's textContent.

Response: The feeling in the group is that there is sufficient difference between the methods. The main reason is that hasProperty can terminate as soon as the first match is found. Search has to continue to find all possible occurrences. In addition there are use cases where knowing that a property exists is sufficient and the exhaustive search can be avoided.


  - There is confusion regarding what exceptions are to be raised,  
DOMException or DCIException. You can't reuse DOMException to add  
your own exception codes because that is highly likely to clash with  
future extensions to the DOM, therefore DOMExceptions must only be  
raised when an existing exception as specified in the DOM is raised,  
for all other uses a DCIException (which could wrap a DOMException)  
has to be used. It's unclear from the draft which is which. The IDL  
only ever mentions DOMException with values it doesn't have (and  
using the strange "raises(DOMException::FOO_ERR)" instead of just  
"raises(DOMException)" with the prose saying which codes may apply)  
and doesn't define DCIException (!) while other parts talk of  
DCIException. Please change the draft to define the latter and to use  
it when DOMExceptions don't apply.

Response: comment accepted. The specification has been amended so that a DCIException is defined and used by other methods.


 - I have trouble understanding the relationship between a DCI DOM
tree and a DOM tree representing an XML document. You extend Node
directly, thereby creating new node types (which is a major issue, as
future versions of the DOM itself may themselves need to add node
types, in which case you would be clashing with them -- this is *not*
a theoretical problem, you are already clashing
with DOM
3 XPath) but you don't clearly define the behaviour of these nodes
when other DOM operations are applied to them. What happens if someone
tries to serialise that DOM? What are the nodeName, baseURI,
attributes, childNodes, first/lastChild, next/previousSibling,
ownerDocument, prefix, or textContent set to for DCI nodes? What
happens if I try to append a DCI node as the child of an element or
attribute node in the DOM, or vice-versa? What happens when I call
cloneNode, compareDocumentPosition, getFeature, getUserData,
isEqualNode, lookupPrefix, etc. on them? The DOM defines this for the
types which inherit from Node, but you don't, which potentially opens
the door to interoperability issues as much is left to
implementations. I would recommend either a) clarifying the
relationship to the DOM (which may constitute major work and is an
error-prone process), b) removing the inheritance from Node (this
requires checking that events would still work, but so long as you
inherit from EventTarget I think you're fine), or c) defining the DCI
tree as a tree of elements (which may never be serialised as XML), and
therefore inheriting from Element (this has the advantage that they
can be dumped as XML easily, but may have issues in that you would
have to specify what happens if a DCI element is imported into another
document). I think that option (b) is likely to be the one that will
remove the largest set of issues with minimal work, especially since
you don't seem to be making much use of the fact that you inherit from
Node, apart from reusing a few fields.


The DCI group see inheriting from the DOM to be the correct and valid
approach for DCI.  In particular we recongize the need to re-use the
DOM to simplify the DCI implementations through the inheritance of the
DOM node. As a result, the DCI interfaces are designed with the DOM as
a key component and the DOM-tree structure to be familiar, minimal and
re-usable for implementors.

To clarify we have added the following to the doc in Section 4.1:Unless specifically stated otherwise the behaviour of DCI is the same as DOM.

In Section 7 (after the list of exceptions)The following text has been added to the doc:Importing, adopting and cloning DCI nodes is platform dependent and in general, authors should be careful when using these methods on a DCI property tree.

The degree of support for cloning, import and adopt methods on DCI nodes is vendor specific. If these methods are not supported implementations must raise the DOM exception 'NOT_SUPPORTED_ERROR'.

For behavior variance with DOM, please see section 7 Conformance where DCI behavior conflicts with that of DOM is specified. In all other cases, the DCI tree behave the same way as mentioned in DOM specification (mentioned in DCI specification - section 7).

Load and save is out of scope for this version of DCI. We anticipate addressing this topic in future DIWG work items.

We have added to the assumptions in Section 2: DCI represents the delivery context. The delivery context is separate from the document markup. The document originates with an author. The delivery context originates with the device, the network etc. DCI nodes are not intended to appear within document markup.

There is a relationship between markup documents and the delivery context. We will investigate this further in the context of DCI in future work.


- Section 2 point 5 has "To be discussed 16th Sept f2f". I assume you don't want that in your CR document :)

Response: corrected.


- Section 3 is a bit wooly, using terminology like "this will build upon the types defined by the W3C DOM working group" (is it not done already?) or "some of the common data types in the DOM include" (is the list exhaustive or not?). It would be best to make the list exhaustive so that implementers immediately know what they need to reuse from the DOM, even if the definitions for the types are left to another specification.

Response: Agreed. The list has been made exhaustive and the conformance section makes clearer the normative dependency to the DOM.


  - You define DOMString as "a Unicode string encoded with UTF-16". I  
would drop the "encoded with UTF-16" since while that's pretty much  
what the DOM and the IDL prescribe, it is something that language  
specific bindings typically override as an implementation detail  
(many languages map DOMString to their native string constructs,  
which are often in UTF-8 internally, even though they can always  
produce UTF-16 on request).

Response: document corrected.


  - This is unclear: "the DOM NodeList interface when used within the  
DCI context would return a DCIProperty instead of a DOM Node". I  
suppose that you mean that NodeList::item() returns a DCIProperty  
instead of a Node? That's somewhat wrong as in most languages that  
enforce some notion of typing it won't be possible to have that  
method return a type instead of another. I think you'd be better off  
saying that NodeList::item() must return Nodes that can be casted to  
DCIProperties, or something along those lines. Also, wherever that's  
the case it needs to be specified normatively (i.e. not in a sentence  
that starts with "for example").

Response: Agreed. The new sentence would be "Within the DCI context, the DOM Node that is returned through the DOM NodeList::item() method call should be interpreted as a DCIProperty". As for the example statement, we prefer to leave it as it is since the preceding statement clearly mandates viewing all DOM calls within DCI context. The sentence, even though normative by nature, is meant to highlight one of the many scenarios that could occur when using DOM calls within DCI context.


 - Unclear as well (in 4.1): "This is independent of the event  
propagation model in the host environment." I think you mean that if  
the host environment dispatches events through carrier pigeons and  
therefore only supports the "flying/cooing event propagation model"  
it still needs to support bubble/capture for DCI, but it could be  
expressed more clearly. Also, have you considered making the capture  
phase optional? Some other DOMs already do that (for instance the SVG  
MicroDOM). The capture phase adds implementation overhead for no  
obvious value (IMHO).

Response: What is meant through that sentence is that DCI has an independent event system that is not tied to the host platform i.e a the DOM document (xHTML for instance) would have its own event propagation system that is independent of DCI eventing. The DCI eventing is taken care of by the DCI platform.

Capture allows a listener to listen for property change events before the event hits the target node. If there are any problems with that then we can make it optional, but I don't see why we need to special case it if we have no problems. The more compliant we are the the DOM event propagation algorithm the better it is.


- You consistently use the word "metadata" (which seems fine to me)  
yet you called the corresponding interface "DCIMetaDataInterface",  
capitalising the 'D' which suggests that it's really "DCI Meta Data  
Interface". CamelCase is already somewhat hard to guess, especially  
for non native speakers, so being consistent and calling it  
"DCIMetadataInterface" is probably best.

Response: aggreed. document corrected.


  - In some places you state that some attributes need to have the  
value NULL, where it's unclear whether that's the string "NULL" (as  
for nodeValue) or the null value. If the former then please consider  
using the latter instead, and if the latter then the normal way of  
flagging it in W3C specifications is to use null  

Response: aggreed. document corrected.


  - "This method is used to determine whether this property  
has a given named property". I find this quite hard to parse, maybe  
you should tag "in its descendants" at the end?

Response: aggreed. document corrected.


  - In 5.3, you seem to indicate that the version is a string that  
has to be "1.0" (for this version), entailing that "1", "1.0.0", etc.  
are invalid and compare differently. Experience shows that if you  
don't state this in excruciating detail people *will* get it wrong  
and perform numeric comparisons.

Response: aggreed. document corrected.


  - In B.2 you use the text/javascript media type which is deprecated  
in favour of application/ecmascript. Also, there is no NULL object,  
just null (though since it hasn't been declared it'll resolve to  
null, but it's still bad practice). If the document intends to be  
XHTML (which it looks to be from the XMLDecl and the namespace) then  
it MUST include the relevant DOCTYPE (yes I know that's terrible, but  
complain to the HTML WG :). The second script element seems to add a  
listener to the head element, it's unclear to me that this element  
ever sees that event.



  - The ob-RFC2119 reference "In this document the key words must..."  
is placed in the introduction, which I assume to be informative. It  
might be best to place it in the conformance chapter.
  - You mention "cell phones", AFAIK this is an americanism to which  
the more generic "mobile phone" (or device) is generally preferred.
  - You talk of "URIs". The terminology this week is "IRIs".
  - When including a diagram, it's nice to also provide an SVG version.
  - "a NodeList with length attribute value of Zero": no need to  
capitalise Zero.
  - "If the return value is true, the node is included otherwise, the  
node is rejected" should be "If the return value is true the node is  
included, otherwise it is rejected."



 - Do you plan on defining a metadata interface more completely in  
the future, or is that completely left up to other specifications?

Response: defining a metadata interface is outside DCI scope, we expect some other specification, or vendors to publish their metadata structures.


  - It seems to me that using the IDL "any" type may cause  
compatibility issues with some languages, do you have a rationale for  
not using DOMObject there?

Response: we use "any" because DOMObject is only available in DOM Level 3. Therefore we kept "any", which we mapped to String or DOMObject, for DOM level 2 and 3 respectively.

Comments received following the Last Call period

Cameron McCormack

Original email: http://lists.w3.org/Archives/Public/www-di/2006May/0011.html

Response: http://lists.w3.org/Archives/Public/www-di/2006Sep/0002.html

Status: Not Acknowledged.

Many of the comments in that email are editiorial in nature and have led to an immediate correction. No response from the Group to the commenter is deemed necessary, other that this statement.


  2  Assumptions

  6. The DCI framework does not specify a required DOM level.
  But in the Conformance section it implies that at least DOM Level 2 is
  required, so perhaps this assumption is false.

WG response: will change text so that at least DOM Level 2 is required.


  3  Datatypes for PropertyValues

  This will build upon the types defined by the W3C DOM working group.
  [...] Some of the common data types in the DOM include:
    * boolean: for values that are either true or false
  Note that while the other other types in the list are, 'boolean' is not
  defined by the DOM IDL and is actually a core part of the OMG IDL.

WG response: the goal is actually to list all the types in the spec's IDL, not just the DOM. So we've clarified by removing 'in the DOM' in: "Some of the common data types in the DOM include...", and we actually added the any type.


The DOM normally handles errors by passing back error conditions. In
  some circumstances, a DOMException may be raised, [...]

   Does "passing back error conditions" mean returning error values from
   function calls?  If so, then DOMExceptions seem to be the actual normal
   way of signifying errors in DOM.

WG response: we have changer our wording to just "The DOM normally handles errors by raising exceptions, for example when a read-only property is modified."


4.1.1  Initialization of Properties

It's not defined what initialization and de-initialization of properties
actually means.  Does it mean added/removed from the tree?  Or does it
mean set to have some value/set to have an undefined value?

WG response: No change. The DCI framework doesn't impose a particular initialization mechanism for setting values on properties and/or attaching a property with a default value onto the DCI tree. Both of these mechanism are left to the providers because they are property specific.


4.1.6  Property Layout

  DCI places no restrictions on names or namespace attributes that
  properties contain.

So the namespaces of properties need not even be syntactically valid
URIs?  While in section 3 it says that "XML namespaces and URIs in
general are treated as being of type DOMString", it does not specifially
say that names must be DOMStrings (although one can infer it from the
methods in the IDLs that take 'DOMString propertyName' arguments).

WG response: we added a sentence saying that property names must conform to XML names, and URI names must be valid per RFC2396.


  Also properties can be placed anywhere within the DCI hierarchy
  (however it is recommended that they follow logical rules that are
  outside the scope of DCI).

I don't know what it means to recommend that properties be organised
according to rules that are not defined.

The sentence (in parenthesis) is a suggestion to use sensible principles, rather than specific rules. DCI is not recommending any normative guidelines for property hierarchy layout. New text (in parenthesis): the rules for hierarchical property layout are out of scope for DCI.


I realise that the example used in this section is meant to demonstrate
how to disambiguate queries that return multiple nodes, but I wonder
about the actual use of a query where the namespace URI is set to "*".
Surely only the combination of a namespace URI and a property name gives
meaning to the property node--after all, B:GPS may be a Gadget
Perhiperal Status property, something unrelated to global positioning
system devices.  I guess my concern is that the query presented isn't a
realistic one.

We understand that the query example is somewhat obscure and unrealistic. However the intent is to illustrate how to disambiguate the same name and namespace values, when they appear to be identical by comparing parent nodes. In addition, as we move to candidate recommendation, we expect to provide (in a separate document) more typical examples of DCI usage.


5.1.1  Attributes

  In DCI context, the DOM Node nodeValue attribute should be the string

Is it really the string "NULL", or should it be the null value (or
perhaps even an empty string)?

WG response: editorial error, text corrected.


  The readOnly attribute is used to determine whether the value
  attribute can be modified. When readOnly is true, any attempt to
  modify the value attribute will result in an exception being raised.
  When readOnly is set to false the value attribute may be changed.

This attribute indicates whether 'value' may be changed, but maybe it
should also indicate whether 'propertyType' may be changed, too, since
changing 'propertyType' will likely result in a different interpretation
of the property.

WG response: agreed. Changed the specification to say that changing the propertyType attribute will raise an exception if readOnly is set to true.


The DCIProperty interface description does not say how a property's
namespace URI and name can be accessed.  Are these meant to be accessed
from the Node interface's namespaceURI/nodeName/localName attributes?

WG response: yes. We clarified the text by reminding that "These methods are defined in addition to the standard DOM interface methods."


5.2  The DCIPropertyFilter Interface

The IDL doesn't say that acceptProperty raises a DCIException, but the
Exceptions section of the prose says that one of type
PROPERTY_FILTER_ERR is raised.  Is this exception inteded to be raised
by authors in their implementation of acceptProperty?  If not, I think
this exception should not be listed here, as it is actually
DCIProperty.searchProperty that raises it.

WG response: the exception is indeed expected to be possibly raised within acceptProperty. We corrected the incorrect function definition.


5.3  The DCIComponent Interface

  The parent attribute of an DCIComponent has the value NULL.

Should this be the 'parentNode' attribute?

WG response: yes. Typo fixed.


The following events are of particular interests to DCI listeners:

Is that any indication of what events are dispatched?  For example, are
the DOMNodeRemovedFromDocument and DOMNodeInsertedIntoDocument ever

WG response: the only event that DCI framework specifies is the dci-prop-change event. However, since the DCI tree is a DOM tree, then the other events stated will be fired. The spec suggests (but does not mandate) some of the events that might be of interest to DCI users, such as DOMNodeRemover.


I suggest that these DOM Events defined event types are included here
just by reference, rather than providing a duplicate description of
these events.

WG response: We are just mentioning some of the events that might be of interest to the DCI spec readers, as means of guidance, with the full awareness that users will indeed follow up with the actual DOM events. And we have added a direct link to the DOM spec.


7  Conformance

  Although, the DCIProperty interface inherits from the DOM Node
  interface, not all of the attributes and methods defined for the Node
  interface are applicable to delivery context properties. In particular


What must happen for attributes and operations on the Node interface
that aren't listed here, such as cloneNode and textContent?  Are they
implementation defined?

WG response: thank you, this was a good catch. We've added the requirement for the textContent attribute to be null if DOM Level 3 is supported. However, the methods specified in the DOM Node IDL are applicable to a DOM DCI tree, subject to security and access policies that are defined outside DCI scope and may be implementation specific.


  Note: The DOM 3 Event Note adds the notions of event namespace, groups
  and categories to the DOM 2 Event Recommendation; these are useful
  features in the DCI context.

DOM Level 3 Events has recently been returned to Working Draft status,
and event groups are at risk of being removed due to lack of use cases.
If these indeed are useful for DCI, you should consider notifying the

WG response: thanks, we are following up with the Web API WG.


B.2  GPS Resolved Postal Code

With this line:

  var location = childProperty(DCI, "location");

Does this imply that a "DCI" property on the ECMAScript global object
is the intended method to expose DCI information to script?  Should this
be specified in the ECMAScript binding section?

And for these lines:

  format.nodeValue ="postal code";
  updateDistance.nodeValue = "50m";
  field.firstChild.nodeValue = location.nodeValue;

shouldn't these references to nodeValue actually be propertyValue
(except for the field.firstChild.nodeValue, obviously)?

WG response: regarding the first comment, access to the DCI object is implementation specific. For example, some browsers can offer DCI as a global object or provide handle to DCI tree through the getFeature call in DOM. Regarding the references to nodeValue, we have corrected these errors.


B.3  Battery Level

The comment about "dcn:getPropertyValue" in the code doesn't seem to be
relevant, given that dcn:search is the XPath function used in the
sel:expr attribute.

This example also doesn't seem to exemplify the interfaces defined by
this document.

WG response: agreed. We have removed the example. Although it seemed interesting to show DCI used in contexts other than scripts, the interface with DISelect access functions isn't specified yet, and we don't want to confuse readers by making something up which might be wrong later.

$Id: disposition-of-comments-CR.html,v 1.4 2007/07/06 15:06:53 jigsaw Exp $