ValueTypes in Different Domains

This page tries to look into various domains and collect information about their "type systems".

Generic Sensor API

The Generic Sensor API states about sensor readings

[...] device sensors measure different physical quantities and provide corresponding raw sensor readings [...]

The assumption is that binary data is sent as string.

JSON schema used to have an attribute "format" to indicate this case (e.g., {type:"string", format:"base64"}) but moved to "contentMediaType" and "contentEncoding" (see JSON Schema Validation spec)

Generic Sensor API design choices that may be useful for WoT

1. Sensor types are associated with common
   • data stream type
   • permission
2. Sensor lifecycle:
   • use constructor, specifying the reading frequency
   • a sensor has the following internal slots: ** state, ** frequency, ** hi-res time stamp for last reading, ** whether observers need notified (as a result if new reading is available)
   • start, stop a sensor (activated state)
   • events for: ** a sensor gets activated (as a result to start()) ** an error condition ** on readings available
3. Controlling data flow (see mitigation section)
   • There is separation of sampling and reporting frequency.
   • Limit max sampling frequency.
   • Limit number of readings.
   • Reduce accuracy.
   • Change reading threshold that triggers new reading.
   • Stop sensor.

Analysis for WoT

* Data flow, sampling/reading frequency etc are part of the Thing model and should not be explicitly exposed in WoT Scripting API. However, the model should reflect these, i.e. in ExposedThing API developers need to be able to specify these as generic Thing properties.
* Start/stop already covered in WoT Scripting.
* Constructor vs factory discussion. 
    ** ConsumedThing objects are always made in factory.
    ** ExposedThing objects could be constructed, then registered. Now we have a factory method.