JSR 256 Maintenance Release Change Log (01 February, 2007)

 

The following table provides the list of issues addressed by the JSR 256 Expert Group during the maintenance phase, including the proposed changes to the specification that will benefit the users (application developers, content providers, and implementers) of JSR 256 specification.

 

#

Issue

Description

Change

Status

1

Appendix E. Sensor definitions

 

There have been customer requests for sensor definition recommendations. The recommendations will help in unifying the sensor implementations accross different manufacturer platforms.

The proposed new appendix will describe needed information for selected sensors, such as data type, unit, and measurement rates.


Sensor definitions mean information that is needed in populating a SensorInfo and a ChannelInfo objects. All the information cannot be defined, because it is vendor specific.

PROPOSED

2

Missing units

There exist sensors, a data type of which is boolean-type or counter-type. It is recommended to use int values 0 and 1 for boolean-type and int with counter-type, but it would be more clear to have special units for these sensors.

The symbol of a unit is used. For 0,1 data "boolean" cannot be used, because the data type is not boolean. There are several options, for example:

  • "sensorBoolean"
  • "0_1"
  • "truth"
  • "logical_value"

For counter-type of data values the options are so far:

  • "unit"
  • "counter"
  • "natural_number"

The symbols are to be decided.

PROPOSED

3

Controllable sensors

The ability to control the sensor was left out not to conflict with the native side controlling. Yet there have been requests to add this functionality

To provide an optional javax.microedition.sensor.control package, which consists of at least a Controllable and Control interfaces. A new system property microedition.sensor.control.version will indicate the presence of the optional package.

The new optional property PROP_CONTROLLABLE should be added to a SensorInfo. If it is missing, the sensor is not controllable. If the property is defined, it must be equal to Boolean.TRUE, in which case the implementation of the sensor must implement the Controllable interface. By having the this property defined an app writer can detect, whether the sensor can be controlled before opening the connection to the sensor.

PROPOSED

4

Accuracy

The problem of missing accuracy information must be solved. Following clarification (in bold font) to the description of a method ChannelInfo.getAccuracy() is proposed

Returns: the accuracy of the channel of the sensor. If the accuracy is not known, a value of -1 is returned.

PROPOSED

5

Uncertainty

There is the problem of defining the uncertainty values if the sensor is not providing them and there is no accuracy given.

If the sensor is not providing uncertainty info and the accuracy of the sensor is -1, then the uncertainty value MUST be always 0.

PROPOSED

6

Model

In the description of a SensorInfo object there is a list of mandatory information, a model is missing from the list.

The model must be added to the list of mandatory fields.

PROPOSED

7

More context types

The list of current context types should be updated

Missing context types have to be added.

PROPOSED