2LC comments on DCI

Hi Cameron,

thank you for your comments:
http://lists.w3.org/Archives/Public/www-di/2006May/0011.html

referencing the 2nd last call of Delivery Context Interfaces (DCI)   
Accessing Static and Dynamic Properties:
http://www.w3.org/TR/2005/WD-DPF-20051111/

The groups responses have been broken-down (below) into sections  
91-18) for  clarity.  The edits will be reflected in:
http://www.w3.org/2001/di/Group/di-dpf/DCI-CR.html

if you have further input to the DIWG responses below, please respond  
by Sept 29th '06.

Cheers,

-Keith Waters


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 the following statement.

Comment: 1
Section 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.

Comment: 2
Section 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.

Comment: 3
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."

Comment: 4
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.

Comment: 5
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  
specifically 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.

Comment: 6
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 organized  
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.

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

Comment: 8
5.1.1  Attributes

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

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.

Comment: 9
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.

Comment: 10
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."

Comment: 11
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.

Comment: 12
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.

Comment: 13
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 fired?

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.

Comment: 14
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.

Comment: 15

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 implementations:

     [...]

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.

Comment: 16
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 Web API WG.

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

Comment: 17
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.

Comment: 18
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.







______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________