DDR Simple API

Hi,

 

I have been having some discussions with other members of the
wmlprogramming mailing list and after taking a look at the current draft
of the "Device Description Repository Simple API" I have found at least
on minor issue with the API as currently defined.

 

For what I have read, the API is lacking mechanisms to discover the
types and values of Properties. To make myself clear, on 4.2.4 it
states: "For the getString method implementations must return an
implementation dependent String representation if the type of the value
is not natively String." There are two readings to this sentence: (a)
Strings will be represented on the native string representation for the
specific language of the implementation; this sounds completely fine.
But another reading (b) would be that the string representation of the
values is dependant on each implementation; now this would mean one
implementation may "display" integer values as binary while another as
decimal or hexadecimal. One implementation may represent Boolean values
as "0"/"1" another as "false"/"true" or "no/yes". This of course would
diminish the usability of PropertyValue.getString() as a way to fetch
values in a universal manner.

 

This would be acceptable if there were a way to discover the type of
Properties. But there is none. 4.2.4.1 provides a mechanism to discover
if a Property exists, but no mechanism to interrogate what is the type
and hence what Retrieval method to use. It seems to me a way to discover
the type of a PropertyValue is needed either directly on PropertyValue
or as an attribute of PropertyRef:

 

             int getPropertyType() : One of constants: LONG_VALUE,
DOUBLE_VALUE, STRING_VALUE, BOOL_VALUE, INT_VALUE, ENUMERATION_VALUE,
FLOAT_VALUE.

 

I am suggesting int constants to keep the API simple and compatible
across languages; as oppose to returning a instance of a Java Enum or
Class.

 

Notice that the DDR implementation itself has to know the type as
otherwise it would not be able to throw the expected exception in case
of error. But without this functionality at the API level there is no
way for programs using the API to do any kind of discovery.

 

Hopping you take my comments into concideration.

 

Regards,

 

Jose Alberto Fernandez

Cellectivity LTD