Extensibility of Attribute Types

We are looking at a scenario where the client is able to render based off the type definitions in the API and not off the specification of the API or its extensions.

Extensions may require extensibility of CAMP's data type mechanism to allow them to supply additional information to the browser about how to render and/or validate attributes of resources.

There are 3 scalar types in json - String, Numeric & Boolean as well as null
In practice if the browser gets one of these it doesn't really need any metadata to determine which one it has received - the type is implicit in the json.

The problem is that a String can actually represent a date, or a time interval, or there can be constraints on the range or number of decimal places in a numeric type. The browser needs to get these constraints in metadata.

The current API specifies 2 additional base types: URI and Timestamp. Timestamp is only used on the Sensor. URI is widely used (see below).

In practice the fact that an attribute is a URI is not adequate to render it in the browser. There are one or two (external management interface and documentation are the only ones I can remember) that aren't references to CAMP resources. The vast majority of URIs are actually references to other CAMP resources (either collections or single resources).
These URIs need special handling in the UI.