DCI Accessing Properties comments

Hi.

I realise that the last call review period for this document has well
passed, but I have only just come across this it and would like to offer
some feedback.  Hopefully you can take them into consideration.

Thanks,

Cameron

-- Comments --

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.

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.

  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.

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?

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

  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.

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.

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)?

  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.

5.1.2.1  hasProperty

  Parameters
  namespaceURI
  The namespaceURI parameter is a DOMString containing the namespace of
  the property being searched. The namespaceURI string may be NULL,
  which denotes a 'wildcard', i.e., it matches any namespace found. 

In the example in 4.1.6, "*" is used as the wildcard argument value
rather than null.

  SYNTAX_ERR: This exception is raised when the syntax for namespaceURI
  or propertyName do not conform to the syntax supported by the DCI
  implementation.

Does this document prescribe any syntax for namespace URIs and property
names?  Presumably namespace URIs must be syntactically valid URIs, but
for property names, having this open to the implementation seems to
invite possible wanton throwing of exceptions.  For example, if an
implementation supports only a single property whose name is "abc", then
arguably the syntax for property names is those that match /^abc$/.
Is the implementation then conformant in throwing exceptions for any
property name it does not recognise?

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?

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.

5.3  The DCIComponent Interface

  The parent attribute of an DCIComponent has the value NULL.

Should this be the 'parentNode' attribute?

6  Event Processing Model

  dci-prop-change:this event is raised after a property changes value.
  This event is targeted at the property that has changed value. If this
  feature is implemented, the event must be in the DCI namespace which
  is: http://www.w3.org/2005/dci.

Except for DCI implementations that support only DOM Level 2 Events?

  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?

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

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?

  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.

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)?

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.

-- Editorial suggestions --

General

Inconsistent spelling:

  * "metadata" and "meta data"

Inconsistent formatting:

  * Strings are sometimes in green, bold, monospace, sometimes in
    regular style.

1  Introduction

  These API's are of particular relevance [...]

s/'//

  For dynamic properties it is important to be able to respond to
  changes when they occur, for example, the devices' new location,
  consequently a mechanism to subscribe and unsubscribe to specific
  events is required.

s/for example, the devices' new location, consequently
 /such as when a device changes location. Consequently,/

  The DCI may well encompass ontologies for device properties and
  characteristics defined by other organizations for example [UAPROF] by
  [OMA] and is therefore outside the scope of DCI.

Since "The DCI" is the subject of the sentence, it sounds like it is
saying that the DCI "is therefore outside the scope of DCI".

s/for example [UAPROF] by [OMA] and is/
 /, for example [UAPROF] by [OMA], and such ontologies are/

4.1  Delivery Context Interfaces Property Hierarchy

  Unless otherwise stated, all DOM entities have to be viewed within the
  DCI context.

I think a word other than "entities" should be used here, as that has a
particular meaning for DOM.  Maybe "interfaces, attributes and
operations"?

5.1.1  Attributes

  Applications can read the valueType attribute to determine type and
  format of property value present in attribute "value".

s/type and format of/the type and format of the/

  This interface allows a scripting author to recognize the mime-type
  contained within DCIMetaDataInterfaceType, and then fetches and
  process the RDF meta data at the URI contained in the
  DCIMetaDataInterface.

s/fetches/fetch/

5.3  The DCIComponent Interface

  The value attribute of an DCIComponent does not have any meaning.

s/an/a/

6  Event Processing Model

  The following events are of particular interests to DCI listeners:

s/interests/interest/

A  IDL Definitions for the DCI

  and DOM events. which are used

s/\./,/

B  Informative Use Cases

All "NULL"s in code should be "null"s.

B.3  Battery Level

  It uses the elements defined by the Content Selection for Device
  Independence specification [DISelect] to select alternative XHTML
  [XHTML]markup according to the current battery level as accessed
  through the Delivery Context Interfaces component using an XPath
  [XPath]expression.

Spaces after "[XHTML]" and "[XPath]".

-- 
 Cameron McCormack			ICQ: 26955922
 cam (at) mcc.id.au			MSN: cam (at) mcc.id.au
 http://mcc.id.au/			JBR: heycam (at) jabber.org

Received on Thursday, 18 May 2006 05:19:03 UTC