[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=62130#comment-62130 ] 

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

Here's a proposal for discussion

URI has two specific meanings
1)	A reference to a CAMP resource.  There are a set of strong constraints on these URIs are that they are valid URIs that resolve to actual resources and that they form a connected digraph of resources that are all valid CAMP resources
2)	A  String that is a (more or less) a valid URI
We need to separate these two meanings.  The vast majority of “URIs”  actually carry meaning 1)See below for a proposal.
Following the HTML5 model I suggest we handle “Strings that is a valid URI” and “Strings that are actually Dates” as Strings with additional qualifiers that mandate how they are to be interpreted.
We are then left with the 4 json base scalar types as well as Lists and Objects
Now we need to add back a way to carry the semantics to allow the client to render appropriately
We have a Formats resource that applies at the platform level that specifies the Json RFC.  This is problematic for the same reasons the typedefinition was problematic at the platform level.  I suggest we lose it and mandate in the spec version  the use of this particular RFC.  We can then use the JSON objects to carry the references to any other standards we want to reference.
We also want to separate the format itself (which may be for example the “full-date from RFC-3339”) from the advice to the browser about how to render and constrain the user input.
So we are have the following attributes on the attribute definition
•	Attribute Type [mandatory] – a String with one of the 4 base Json type names plus Ref [do we actually need this?} 
•	Format Standard –[Optional] a string reference to a standard such as RFC-3339  or CAMP!!!
•	Render Standard – [Optional] a string reference to a standard such as HTML5
•	Render Type – A string reference that makes sense in the render Standard (e.g. an HTML 5 input ype) 
•	Render Attributes – an array or map of attributes that qualify the  Render Type and make sense in terms of the Render Standard



> 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)