[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=34573#action_34573 ]
Jacques Durand commented on CAMP-83:
-------------------------------------
New uploads:
Most current TA draft:
https://www.oasis-open.org/apps/org/workgroup/camp/download.php/50585/camp-ta-v1.1-wd10.doc
the proposed updates to CAMP spec:
https://www.oasis-open.org/apps/org/workgroup/camp/download.php/50586/camp-spec-v1.1-wd20-r1-NewNormTags-d.doc
PROGRESS:
=== Total mandatory normative tags in current spec draft:97
=== Current number of TAs: 119
(NOTE: relationship TA-to-NormTAG is often many to many)
=== Match of current TAs to current mandatory NormTAGs: 76 (out of 97)
=== Match to missing NormTAGs that are proposed (see (CAMP-83, proposed updates to CAMP spec) : 18 (out of 18)
=== Testability-challenged NormTAGs: 15 (to be discussed)
=== Remaining NormTAGs for which testing seems possible: 5
CHALLENGES: (- to add to those in previous comments:)
- in RE-36: how to determine the "corresponding" PCC, for a PCT or PCR?
(no explicit link, the matching (PC+PCC)<->PCT is not finegrain.
- In 5.13 (PlatformComponentTemplate Resource)
Shouldn't we have a requirement:
"Providers SHALL NOT support the HTTP DELETE method on instances
of the PlatformComponentRequirement resource " ?
- Shouldn't there be a parameterDefinitionsUri on any resource that accept (or may accept) a POST?
> 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]