Substantive comments on DPF

Hi

this is the second of four related messages:
   - editorial comments
   - substantive comments
   - RDF related comments
   - brief biographical introduction


This message contains comments on

http://www.w3.org/TR/2004/WD-DPF-20041122/

This set of comments are substantive in nature.


s1.
Lack of relationship with DOM element and hence
awkwardness of XPath or ECMAScript expressions

In Appendix A DPFProperty is not related to a DOM element.
However, in Appendix B and in section 2 numbered point 2,
expressions in XPath and ECMAScript are presented that
involve navigating the tree of properties as if it were
a tree of XML elements. This results in a number of related
bugs.

s2.
Incompleteness of ECMAScript binding

The intent in section 2 point 2 is that ECMAScript expressions
such as "a.b.c[2]" should interact with the specification of
DPF. It is not specified as to how this is done.

s3.
XPath expressions over properties

The intent in section 2 point 2 is that XPath expressions
such as "/a/b/c[3]" should interact with the specification of
DPF. It is not specified as to how this is done.

s4.
Colon (:) in identifiers

Section 2 point 2 defines the set of valid property names
in a way that excludes :. This leaves it unclear as to how
namespace information should be included in XPath expressions
or ECMAScript expressions that navigate a DPFProperty tree.

s5.
Identical names in different namespaces

Figure 2 presents the possibility of the use of identical names
in different namespaces. The intent appears to be that DPF should
provide a framework in which different properties
independently defined by different namespace owners can interoperate.
However, the ECMAScript expressions are unable to distinguish namespaces
and the semantics of an expression like "gps.gps" is unclear for figure 2.


s6.
Add/remove events should be defined in DPF

Penultimate para of 4.1.4 leaves open whether add/remove events
should be standardized. It seems to be that they should, since
they are needed and generic, and a lack of standardization is
an easily avoidable interoperability failure.

s7.
Metadata is unusable

The end of 4.2.1 provides a metadata interface, but with no
indication of what are the legal values for either of the
two attributes they are unusable - they have no semantics.
My preference is to delete these attributes and say that
metadata about a property (i.e. the concept that is being used,
rather than the value of the property in this particular context)
should be provided in RDF/XML at the URI created by concatenating
the namespaceURI with the name (as in RDF/XML).

s8.
NOT_FOUND_ERR

In 4.2.2 The method signature of appendDPFProperty appears to be
incorrect in that NOT_FOUND_ERR cannot occur.

s9.
SYNTAX_ERR

It's very unclear what this means. What syntax has been violated?
The description in 4.8 talks about 'invalid or illegal' (what's the 
difference
between 'invalid' or 'illegal') strings. The exception appears on
many methods with no string arguments, and does not appear in 
searchDPFProperty.

s10.
TYPE_MISMATCH_ERR
property type

No definition of property types is given and so both these concepts
used extensively are coherent. This should be fixed somehow.
See my RDF related comments for my suggestion as to how.

s11.
inconsistency needs discussion

Section 4.1.2 describes the use of DPF in distributed systems.
Within these, latencies are such that inconsistency is likely.
The DPF specification should take a position such as inconsistent
values may be returned to the application, and the application has
to deal with it, or that given some appropriate additional methods
the application can get a consistent snapshot of the state.

s12.
wildcards in hasDPFProperty

Is it a mistake to have omitted the use of the wildcards in 4.2.7
from 4.2.6 hasDPFProperty? Since implementors need to write the code
anyway, they may as well apply in both methods.

s13.
NULL as wildcard?

In section 4.2.7 NULL is used as the wild card. Wouldn't "*" be better,
to avoid misinterpreting programmar error resulting in null pointers.

s14.
item(335) INVALID_ACCESS_ERR or NULL

Section 4.3 declares an INVALID_ACCESS_ERR on the item() method,
but does not specify it's use. Rather the specification is to return
NULL. I suggest the specification should be changed to
throw an INVALID_ACCESS_ERR when the index is out of range.


s15.
4.3.2 exception on removal better?

I was surprised that accessing a property that has been deleted is
not an exception. If the WG has already considered and rejected such
a design choice, this comment is already adequately addressed. Otherwise
please consider it.

s16.
Event categories underspecified in section 5

The fifth para of section 5 sketches the use of wildcards to create
event categories. This sketch is insufficiently complete to
build interoperating implementations.

s17.
Language considerations

The specification of DPF provides no capabality to add language tagging
to string values of DPFProperties.


Jeremy Carroll

Received on Monday, 10 January 2005 18:40:01 UTC