[OASIS Issue Tracker] Commented: (CAMP-30) Parameter Scheme

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

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

Adrian Otto commented on CAMP-30:
---------------------------------

Based on feedback from our last review, I am thinking about how to make a clean distinction between parameters that influence processing of a POST request, and a parameter that should set an attribute when a new resource is created.

I considered if the addition of PATCH might reduce the need for some or part of the parameter scheme. I don't think it does. The purpose of the parameter scheme is to allow the creation of resources that have attribute values that are set at creation time. Using PATCH would require that the resource is first created with a POST, and then updated in a subsequent step with PATCH. I really want to allow one-step creation of new resources that have customized attribute values.

I can think of two common use cases for the feature:

1) When creating a new resource, set its name to a unique value by passing it in at creation time.

2) When supplying additional information with the POST beyond the request itself, such as sending the URI of the PDP to create an AssemblyTemplate resource.

In use case #1, the value of the parameter should be copied by the Platform into an attribute in the new resource it creates.

In use case #2, the value of the parameter is not copied into the new resource. It is only used by the Platform to facilitate the creation of the new resource.

One potentially elegant solution to this problem was suggested by Anish. It involves allowing the URI in the parameters attribute of the template resource in one of two ways:

1) A URI that points to an attributeDefinition resource. In this case, it creates/sets the attribute described by that resource using the value supplied when the parameter is passed in the POST Body.

2) A URI that points to an parameterDefinition resource. In this case, the value is available to the Platform, but there is no expectation that an attribute value will be set in the new resource.

Alex mentioned that he has a use case where a client may supply a range of values in a parameter, and the Platform may choose a value in the range, and set that selected value in an attribute in the new resource. In that case, he would use a parameterDefinition resource in combination with an Extension. The documentation in the Extension would describe what attribute will be set in the new resource, and what it will be set to.

To support Alex's use case the parameterDefinition resource should have an optional attribute extensionUri that references the Extension Resource that that contains the documentation about the Extension that contains the special processing logic for range value selection.

Thoughts? 

If there are no objections, I plan to revise the proposal accordingly.

> Parameter Scheme
> ----------------
>
>                 Key: CAMP-30
>                 URL: http://tools.oasis-open.org/issues/browse/CAMP-30
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: Improvement
>          Components: Spec
>            Reporter: Adrian Otto
>            Assignee: Adrian Otto
>            Priority: Critical
>
> Create a well defined template parameter scheme that can be used to express special labels in template resource attributes that are used for supplying values upon instantiating entities using the template. In addition to a template parameter label, we also need a standard mechanism to specify values for the labels when using the API.
> This feature can be used for supplying a unique name to an Application Assembly at the time it is created and started. This would allow multiple Application Assemblies to be created from the same template to run concurrently, and offer a way to easily tell them apart from each other. The scheme should be flexible such that it works for Component Templates as well, so that it can be used for passing in configuration parameters that are employed by a downstream configuration management system.

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