[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Issue Comment Edited: (CAMP-40) version array resource/thing has a number of problems
[ http://tools.oasis-open.org/issues/browse/CAMP-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=32473#action_32473 ]
Gilbert Pilz edited comment on CAMP-40 at 2/14/13 7:52 PM:
-----------------------------------------------------------
With respect to Alex's comments, the version of my proposal that uses Map uses the specificationVersion and implementationVersion as keys in a two-level Map. To clear some things up:
1. Every Platform resource must have a "name" attribute. The value of this attribute does not have to be unique, nor does it have to have anything to do with the version of CAMP implemented by the tree of resources rooted in that Platform.
2. The Link type requires that the value of the mandatory "targetName" attribute must be equal to the value of the "name" attribute of the thing that is being referenced by that Link. There is no wiggle room on this. If you want your Links to reflect anything more than the URI and name of the target resource, you need to extend them.
3. Every Platform resource must have the "specificationVersion" (I just realized this is an array) and may have an "implementationVersion". The former lists the version(s) of the CAMP spec implemented by the tree of resources rooted in the Platform and can only have values that are canonical CAMP specification versions e.g. "CAMP 1.1", "CAMP 2.0", etc. The later is an optional, provider-specific version string. This allows providers to sub-version their CAMP implementations if they need to do so.
It turns out that my St. Valentine's Day proposals are a bit off in that "specificationVersion" is an array (so which value do you use as they key?), and "implementationVersion" is optional (so what happens if it's not there - does the sub-map go away?)
was (Author: gilbert.pilz):
With respect to Alex's comments, the version of my proposal that uses Map uses the specificationVersion and implementationVersion as keys is a two-level Map. To clear some things up:
1. Every Platform resource must have a "name" attribute. The value of this attribute does not have to be unique, nor does it have to have anything to do with the version of CAMP implemented by the tree of resources rooted in that Platform.
2. The Link type requires that the value of the mandatory "targetName" attribute must be equal to the value of the "name" attribute of the thing that is being referenced by that Link. There is no wiggle room on this. If you want your Links to reflect anything more than the URI and name of the target resource, you need to extend them.
3. Every Platform resource must have the "specificationVersion" (I just realized this is an array) and may have an "implementationVersion". The former lists the version(s) of the CAMP spec implemented by the tree of resources rooted in the Platform and can only have values that are canonical CAMP specification versions e.g. "CAMP 1.1", "CAMP 2.0", etc. The later is an optional, provider-specific version string. This allows providers to sub-version their CAMP implementations if they need to do so.
It turns out that my St. Valentine's Day proposals are a bit off in that "specificationVersion" is an array (so which value do you use as they key?), and "implementationVersion" is optional (so what happens if it's not there - does the sub-map go away?)
> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]