[OASIS Issue Tracker] (CAMP-200) Extensibility of Attribute Types

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/CAMP-200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=62168#comment-62168 ] 

Michael Norman commented on CAMP-200:
-------------------------------------

Following discussion at the TC and some additional thought I think we maybe have gone down a wrong turning in focusing on HTML5.

The reason why we proposed separating the Format Standard from the Render Standard is that we considered the Format standards to be more permanent than the Renderer i.e. Browser standards, and to apply to clients other than Browsers (e.g. automation clients). However as Gil pointed out, there is addiitonal information that such a client (such as range etc.) that might  want that isn't expressible in the Format itself, and so we end up either expressing this in HTML5 (which seems wrong) or providing multiple Render Standards which seems like it's a duplication.

I think the right resolution to this (and possibly to the filtering and sorting issues) will be found at the JSON level. We already use the JSON Pointer syntax to define the consumer mutable constraint at the JSON level, and these kinds of "range" constraints feel very similar.



> Extensibility of Attribute Types
> --------------------------------
>
>                 Key: CAMP-200
>                 URL: https://issues.oasis-open.org/browse/CAMP-200
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: Bug
>          Components: Spec
>    Affects Versions: 1.2
>            Reporter: Michael Norman
>            Assignee: Anish Karmarkar
>
> 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. 



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)