[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=34503#action_34503 ] Jacques Durand commented on CAMP-83: ------------------------------------- Uploads: current TA draft: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/50495/camp-ta-v1.1-wd08.doc (camp-ta-v1.1-wd07.doc) PROGRESS: === Current number of TAs: 90 (74 last upload) === Coverage: (current mandatory NormTAGs addressed):: 46 (out of 97 mandatory) (+ 5 non-mandatory) CHALLENGES: - (PDP-20, and others similar): Providers SHALL NOT regard the order of the ArtifactSpecifications within this array as semantically significant. [PDP-20] Propose to reword: "Unless otherwise agreed with the Provider, Consumers SHALL NOT assume that the order of the ArtifactSpecifications within this array implies a particular processing order by the Provider". [PDP-20] - testability challenge: RE-14 ". However, it SHALL NOT contradict the HTTP status code that is returned with the request. " - scope: RE-16 and RE-21 oversteps what the CAMP specification can require: it is not its role to say what future versions can/cannot do (?). "Because of the unique function of this resource, future versions of the specification SHALL NOT make non-backwards compatible changes to this resource. " - About Link attributes: RE-01, RE-03, RE-04: instead of these requirements, why not just use the current attribute metadata - for href: Type: URI Required: true Mutable: true Consumer-mutable: true - and for targetName (RE-31) Type: string Required: true Mutable: true Consumer-mutable: false - need to clarify if POST can be used against other resources than Platform (RE-55) and AssemblyTemplate (RE-56). > 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]