thank you for your comments:
referencing the 2nd last call of Delivery Context Interfaces (DCI) Accessing Static and Dynamic Properties:
The groups responses have been broken-down (below) into sections 91-18) for clarity. The edits will be reflected in:
if you have further input to the DIWG responses below, please respond by Sept 29th '06.
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.
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.
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.
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 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.
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.
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..
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 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.
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.
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.
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.
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.
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
|Free forum by Nabble||Edit this page|