OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

camp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] (CAMP-196) should links attribute of collection resource be consumer mutable


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

Gilbert Pilz edited comment on CAMP-196 at 8/10/15 6:47 PM:
------------------------------------------------------------

I think this issue is difficult to address because the "collection resource" is used in different ways throughout the resource model. There a couple of patterns to this usage. There are the top-level directory/catalog collections: supported format collection, extension collection, type definition collection, service collection, etc. (the assembly_factory and plan_factory resources are specialized instances of this pattern). Another pattern is the "container of sub-resource": assembly:component_collection, assembly:operation_collection, component:sensor_collection, etc.

I think it is obvious that some of the usages of the collection resource should not allow Consumers to update the "items" array. In particular, none of the top-level directory/catalog collections should allow this - including assembly_factory and plan_factory. So our choices are:

A.) Allow collection:items to be directly updated by the Consumer (using HTTP PATCH with JSON Patch) on *some* collection resources but not others.

B.) Do not allow collection:items to be directly updated up the Consumer on *any* collection resources.

(A) is conceptually more complicated but certainly doable.

If we go with (B)  we are constraining the usage of collections for every pattern in which they are used. This may be perfectly fine, but I think we need to examine every place collections are used and make sure we aren't shooting ourselves in the foot. In other words, is there anyplace in the resource model where we use the collection resource that it is obvious that we need to allow Consumers to directly manipulate the "items" array?


was (Author: gilbert.pilz):
I think this issue is difficult to address this issue because the "collection resource" is used in different ways throughout the resource model. There a couple of patterns to this usage. There are the top-level directory/catalog collections: supported format collection, extension collection, type definition collection, service collection, etc. (the assembly_factory and plan_factory resources are specialized instances of this pattern). Another pattern is the "container of sub-resource": assembly:component_collection, assembly:operation_collection, component:sensor_collection, etc.

I think it is obvious that some of the usages of the collection resource should not allow Consumers to update the "items" array. In particular, none of the top-level directory/catalog collections should allow this - including assembly_factory and plan_factory. So our choices are:

A.) Allow collection:items to be directly updated by the Consumer (using HTTP PATCH with JSON Patch) on *some* collection resources but not others.

B.) Do not allow collection:items to be directly updated up the Consumer on *any* collection resources.

(A) is conceptually more complicated but certainly doable.

If we go with (B)  we are constraining the usage of collections for every pattern in which they are used. This may be perfectly fine, but I think we need to examine every place collections are used and make sure we aren't shooting ourselves in the foot. In other words, is there anyplace in the resource model where we use the collection resource that it is obvious that we need to allow Consumers to directly manipulate the "items" array?

> should links attribute of collection resource be consumer mutable
> -----------------------------------------------------------------
>
>                 Key: CAMP-196
>                 URL: https://issues.oasis-open.org/browse/CAMP-196
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: Bug
>            Reporter: Tom Rutt
>            Assignee: Tom Rutt
>
> The resolution to issue 192 has the links attribute of the collection resource as Mutable true.
> However it does not make a requirement for it to be consumer mutable true or false.
> In cases of shared components, the administrative user may need to update the collection member links



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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]