[OASIS Issue Tracker] Commented: (CAMP-40) version array resource/thing has a number of problems

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

    [ http://tools.oasis-open.org/issues/browse/CAMP-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=32450#action_32450 ] 

Alex Heneveld commented on CAMP-40:
-----------------------------------

Gil suggested using a map instead.  I am against that.

This raises the issue of consistency with data structures used elsewhere.

For most things we use  Link[].  Here we are deliberately not doing this because including the Version object inline is more useful.  That makes sense.

If we were to use a map here, however (e.g.  Map<versionId, Version>) then arguably we should do that consistently throughout the document.  Thus our  Link[]   items become   Map<targetName,Link>.  In both cases there is repetition where targetName is also included in the Link object, and versionId is in the Version object, as well as being the key in each case.  So for efficiency we probably do NOT want a map in either case.

A client can of course trivially create a map for their own use from our lists, so making the JSON be a map doesn't buy us much, does it?


> version array resource/thing has a number of problems
> -----------------------------------------------------
>
>                 Key: CAMP-40
>                 URL: http://tools.oasis-open.org/issues/browse/CAMP-40
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: Bug
>          Components: Spec
>            Reporter: Gilbert Pilz
>            Assignee: Gilbert Pilz
>
> There are a couple of problems with the version array resource/thing defined in section 6.8.
> 1.) Unlike all the other things you can use HTTP GET to retrieve, the array of available versions is not defined as a first-class resource (i.e. it has no "type", "uri", "name", etc.) In the interests of simplicity it would be better if clients didn't have to special case the code that retrieves the version array.
> 2.) Placing the version array resource "under" the platform resource (i.e. at <platform-url>/api/versions) creates an inherent aliasing problem. For example, suppose a provider concurrently supported by CAMP 1.1 and CAMP 1.2. They might have a "Versions" resource that looked like the following:
> [
>   { "version" : "1.1", "href" : "http://camp.example.org/1.1";, "name" : "nCAMP 0.9 POC" },
>   { "version" : "1.2", "href" : "http://camp.example.org/1.2";, "name" : "BaseCAMP 1.0" }
> ]
> Should a client expect to be able to retrieve this resource through either "http://camp.example.org/1.1/api/versions"; or "http://camp.example.org/1.2/api/versions"; ? Should a client expect the representation of the resource at "http://camp.example.org/1.1/api/versions"; to be the same (baring any unexpected updates) as the representation of the resource at "http://camp.example.org/1.2/api/versions";? If we did decide to represent the version array as a first-class resource, what should the value of its "uri" attribute be?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira