[OASIS Issue Tracker] Issue Comment Edited: (CAMP-83) Labeling of Normative Statements is incomplete (aka overhaul V2)

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

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

Jacques Durand  edited comment on CAMP-83 at 8/24/13 1:48 AM:
--------------------------------------------------------------

Response to Gil's comments:

1)  "Instantiation" vs "realization".
My main concern with overloading "instance of" as both  (a) a resource generated from a Template, and (b) just any particular avatar of a particular datatype, is that we get into confusing statements like:
"The Application Component resource represents an instantiated instance of an Application Component Template,"
What is an "instantiated instance"?  I never saw that expression in 30 years of software engineering...
I don't pretend I have the right answer, but it would be much better if we could have a different term or expression for these two kinds of relationships: (a) from resource X to resource XTemplate, and (b) from an actual object of type X to its resource type X.

2) Agree.

3). Indeed there is nowhere in the spec to back this up - but there is nothing also to preclude this. Need clarification either way.

4) How about: " On reception of an HTTP PUT request, a Provider SHALL update all the Consumer-mutable attributes of the target Resource - and only these -  with the values of corresponding attributes present in the request, when these request's values are different from those of the Resource."

      was (Author: jdurand2):
    Response to Gil's comments:

1)  "Instantiation" vs "realization".
My main concern with overloading "instance of" as (a) a resource generated from a Template, and (b) just any particular avatar of a particular datatype, is that we get into confusing statements like:
"The Application Component resource represents an instantiated instance of an Application Component Template,"
What is an "instantiated instance"?  I never saw that expression in 30 years of software engineering...
I don't pretend I have the right answer, but it would be much better if we could have a different term or expression for these two kinds of relationships: (a) from resource X to resource XTemplate, and (b) from an actual object of type X to its resource type X.

2) Agree.

3). Indeed there is nowhere in the spec to back this up - but there is nothing also to preclude this. Need clarification either way.

4) How about: " On reception of an HTTP PUT request, a Provider SHALL update all the Consumer-mutable attributes of the target Resource - and only these -  with the values of corresponding attributes present in the request, when these request's values are different from those of the Resource."
  
> Labeling of Normative Statements is incomplete (aka overhaul V2)
> ----------------------------------------------------------------
>
>                 Key: CAMP-83
>                 URL: http://tools.oasis-open.org/issues/browse/CAMP-83
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: Improvement
>          Components: Spec
>         Environment: Need more complete tagging of normative statements  for supporting Test Assertions
>            Reporter: Jacques Durand 
>            Priority: Critical
>
> Need more complete tagging of normative statements for supporting Test Assertions.
> There are obvious test assertions needed for defining Conformance, that do not have a clear match to current normative labels.
> This is a partial list. referring to camp-spec-v1.1-wd20-r1.doc:
> 1. Intro of Section 5:
> "The following sub-sections describe the resources defined by this specification."
> Need in addition at least a blanket normative statement like: 
> "When supporting a Resource, a Provider SHALL  implement it and serialize it as described in this section.[NEW-01]. 
> A Consumer SHALL serialize resource data in its requests according to this section [NEW-02]. "
> ------------------------------------------------------------
> 2.  In 5.4 Error Response Message Resource (HTTP codes):
> "Successful requests will generally return an HTTP status code of 200 (OK), ..."
> replace with:
> "Providers SHALL use HTTP codes accordingly to their common interpretation,  
> i.e. return an HTTP status code of 200 (OK), ..."[NEW-03].
> ------------------------------------------------------------
> 3. In 5.4 Error Response Message Resource
> "the server is encouraged to include a response message  ..."
> replace with
> "the server SHOULD include a response message  ..."..."[NEW-04]
> ------------------------------------------------------------
> 4. in 6.12  Instantiating an Application
> replace
> "On success the server creates an Assembly resource and sends a 201 Created HTTP status code 
> with the Location header in the HTTP response. "
> with:
> "On reception the Provider SHALL create an Assembly resource and send a 201 Created HTTP status code 
> with the Location header in the HTTP response. "[NEW-05]
> Also:
> "The Location header points to the newly created Assembly resource. " --> 
> "The Location header SHALL point to the newly created Assembly resource. " [NEW-06]
> And:
> "The server also updates the AssemblyInstances attribute of the Platform resource to include a reference to..." -->
>  "The Provider SHALL update the AssemblyInstances attribute of the Platform resource to include a reference to..." [NEW-07]
> ------------------------------------------------------------
> 5. In 6.11:
> replace:
> "A Provider supports registering a PDP using the ZIP [ZIP], TAR [TAR], and GZIP [GZIP] compressed TAR format. "
> with:
> "A Provider SHALL support registering a PDP using the ZIP [ZIP], TAR [TAR], and GZIP [GZIP] compressed TAR format. " [NEW-08]
> ------------------------------------------------------------
> 6. Section 6.11.1  (Registering an Application by Reference)
> replace
> "To register an application by reference, a Consumer sends a POST HTTP request to the Platform URL. "
> with:
> "To register an application by reference, a Consumer SHALL send a POST HTTP request to the Platform URL, 
> as described in this section . "  [NEW-09]
> Also replace:
> "On successful registration of the application, the Provider creates an AssemblyTemplate resource and 
> sends a 201 Created HTTP status code with the Location header in the HTTP response. "
> with:
> with:
> "On reception the Provider SHALL create an AssemblyTemplate resourc and send a 201 Created HTTP status code 
> with the Location header in the HTTP response. " [NEW-10]
> Also:
> "The Location header points to the newly created AssemblyTemplate resource. " --> 
> "The Location header SHALL point to the newly created AssemblyTemplate resource. " [NEW-11]
> And:
> "The Provider also updates the assemblyTemplates attribute of the Platform resource to include a reference to the newly created AssemblyTemplate."-->
>  "The Provider SHALL update the assemblyTemplates attribute of the Platform resource to include a reference to..." [NEW-12]
> ------------------------------------------------------------
> 7. Section 6.11.2 (Registering an Application by Value)
> replace
> "To register an application by value, a Consumer sends a POST HTTP request to the Platform URL. "
> with:
> "To register an application by value, a Consumer SHALL send a POST HTTP request to the Platform URL, 
> as described in this section . "  [NEW-13]
> Same remarks as in comment #7, leading to :
> [NEW-14]
> [NEW-15]
> [NEW-16]

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