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] Issue Comment Edited: (CAMP-83) Labeling of Normative Statements is incomplete (aka overhaul V2)


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

Jacques Durand  edited comment on CAMP-83 at 8/21/13 6:47 AM:
--------------------------------------------------------------

See upload proposal with additional normative tags in:
https://www.oasis-open.org/apps/org/workgroup/camp/document.php?document_id=50380

Additional notational issues in the specification as resulting from the need to have precise terminology and normative statements:

1. State changes: (related to CAMP-31): there is no more "state" attribute in run-time resources such as Assembly. How do we track and verify  the state-changing operations? (new-state =...)

2. Notation about resources is fuzzy:. We need to settle for tighter conventions.
Assembly template  (6.14)
Assembly Template
AssemblyTemplate resource

And sometimes we use "instance of XYZ resource", sometimes just "XYZ resource":
In 5.9 "In addition to the methods defined in Section 5.5, "HTTP Method Support", Providers SHALL support the HTTP POST and DELETE methods on instances of the AssemblyTemplate resource. [RE-56]

...DELETE methods on AssemblyTemplate resources

Same in 5.16: "In addition to the methods defined in Section 5.5, "HTTP Method Support", Providers SHALL support the HTTP DELETE methods on instances of the Assembly resource as described in Section 6.14, "Deleting an Application Instance and a Deployed Application
And (5.17)
In addition to the methods defined in Section 5.5, "HTTP Method Support", Providers SHALL support the HTTP DELETE method on instances of the ApplicationComponent resource. [RE-62]


      was (Author: jdurand2):
    Additional notational issues in the specification as resulting from the need to have precise terminology and normative statements:

1. State changes: (related to CAMP-31): there is no more "state" attribute in run-time resources such as Assembly. How do we track and verify  the state-changing operations? (new-state =...)

2. Notation about resources is fuzzy:. We need to settle for tighter conventions.
Assembly template  (6.14)
Assembly Template
AssemblyTemplate resource

And sometimes we use "instance of XYZ resource", sometimes just "XYZ resource":
In 5.9 "In addition to the methods defined in Section 5.5, "HTTP Method Support", Providers SHALL support the HTTP POST and DELETE methods on instances of the AssemblyTemplate resource. [RE-56]

...DELETE methods on AssemblyTemplate resources

Same in 5.16: "In addition to the methods defined in Section 5.5, "HTTP Method Support", Providers SHALL support the HTTP DELETE methods on instances of the Assembly resource as described in Section 6.14, "Deleting an Application Instance and a Deployed Application
And (5.17)
In addition to the methods defined in Section 5.5, "HTTP Method Support", Providers SHALL support the HTTP DELETE method on instances of the ApplicationComponent resource. [RE-62]

  
> 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




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