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

David Laurance commented on CAMP-200:
-------------------------------------

Background:
1. There is a mechanism by which the CAMP type is expressed
2. There is a list of base CAMP types
3. There are then a set of extended types

Our clients are meta-programmed; they read the type definitions and build the UI from them.
Design goals:
* We need to support all HTML5 types in our clients in a way that can be supported by the base CAMP specification, and does not require a revision to the CAMP specification if a new HTML5 type emerges.
* We DO NOT want to duplicate any significant part of the HTML5 specification, even while we want to support a mapping from HTML5 to CAMP.
* We want base CAMP types to be defined cleanly, so that it is clear how each type is handled by a CAMP service.

We have an existing challenge in CAMP where a URI may either:
1) refer to some CAMP resource, or
2) refer to some outside resource, web address, or other entity outside of the CAMP context.
In the RDF world, the second of these cases is termed an "Annotation URI," meaning that the URI is provided as an annotation rather than a reference-able resource.

If the URI is intended to refer to a CAMP resource:
* there is a valid set of resources that, in theory, forms a 'drop-down' or selection box to edit the resource.
* you may need to support a "new" option, that should generate a valid URI, add it to the list, and then create the resource.

If the URI is external to CAMP:
* there may be a valid set of resources, but in general, the value set is under control of the client.
* CAMP cannot make an assumption about whether the target resource is editable, because the target resource does not belong to CAMP.



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