[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Commented: (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=34454#action_34454 ] Jacques Durand commented on CAMP-83: ------------------------------------- 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]