[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Created: (CAMP-100) 3.4 Removing Assemblies and Assembly Templates
3.4 Removing Assemblies and Assembly Templates ---------------------------------------------- Key: CAMP-100 URL: http://tools.oasis-open.org/issues/browse/CAMP-100 Project: OASIS Cloud Application Management for Platforms (CAMP) TC Issue Type: Bug Components: Public Review Reporter: Gilbert Pilz Patrick Durusau submitted the following PR comment (https://lists.oasis-open.org/archives/camp-comment/201309/msg00042.html): The first three paragraphs of 3.4 Removing Assemblies and Assembly Templates reads (with highlighting for problematic terms): ***** When finished working with an application, an Application Administrator can delete an Assembly using a DELETE request. The CAMP platform *will typically soon thereafter* remove the Assembly resource and all associated resources which are dedicated to that Assembly, such as Application Components. Where such a resource is not removed immediately, for example, when it is in the process of shutting down, *it ought to* present a representation skew of DESTROYING in the interim. When the original Assembly Template is no longer needed, an Application Administrator can, *again,* delete it using a DELETE request. *Again,* the CAMP platform will typically delete the Assembly Template and all associated resources which are dedicated to that Assembly Template. Where this deletion is accepted but not immediate, such as because an Assembly is in use that references the Assembly Template, *again* the CAMP platform *ought to present* a representation skew of DESTROYING for the resources being deleted. Following a lifecycle where an Assembly Template is created, then an Assembly is created, then the Assembly is deleted, then the Assembly Template is deleted, the model of Resources in the CAMP Provider *will typically look similar to* the initial model shown in Figure 3-1. ***** 1) The language *will typically soon thereafter*, *it ought to*, *ought to present*, which are just examples, make me doubt that all of Section 3 is normative text. I would find it difficult if not impossible to guess whether another implementer will follow a "typically soon," or "ought to" instruction. 2) More editorial in nature is the second paragraph which appears to be an attempt to restate the first paragraph using "again." Typically standards follow the DRY (Don't Repeat Yourself) principal. If you say what is meant clearly, once should be enough. At least in normative prose. -- 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]