[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [camp-comment] 3.4 Removing Assemblies and Assembly Templates
Patrick, This comment has been captured as Jira issue CAMP-100 and will be processed by the TC. We will inform you when this issue has been resolved. ~ gp On 9/5/2013 10:45 AM, Patrick Durusau
wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings! 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. Hope everyone is having a great day! Patrick - -- Patrick Durusau patrick@durusau.net Technical Advisory Board, OASIS (TAB) Former Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) Another Word For It (blog): http://tm.durusau.net Homepage: http://www.durusau.net Twitter: patrickDurusau -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSKMMqAAoJEAudyeI2QFGoZMEP/175OczJDBAcOTWvQp0X9dxl E+Wf78MMz6ZE1RDbf1TrqofxxFZPIDtLe5LhIJNrY69RxX1vZ9EO5GyJAri1mD9z KlFG0hwSgmm+8VW1HG2K6Fhkvm3Ka9YRGlGDBZ+vIRXAor0TNp4BBE1MX0s3I7J7 8y4RRkc71d5jvnl6yC8uRONKUuK+E2X00fx76qzNwhpUppebUSFqysk1rdhhVuoq E8evLwaR9yIWC45W/ueDdbbmYXfAXqpl64Y2pzN3mYSYalC96v7eoitpgrnQH1em Cq4Et2HD3AH5b0Qd3aV2p3IumzplgOnXS/GDwNotyXGpDQnNnhtU9HfwBP6HGAMw lG/aJFvI3aoZsIXx+sFWpoityLWDLMbnF6XIe98k37t90KaffY7H5G1gtXQGqDRQ LbP1xo7nruEwseJZ6bWN/TZ4qPB5rETlCTg8/v1j6HAApK7qadB3MqUWC2qEfpsm xG77uXG2npBGImy0Lx9iW+Sz+rPS2uH7/3rIRxZekDltVl0dDyxlQRcl8w66HMfQ xbefMFTqA5P8tGi8XkdysfEKEISuKOOXNDNDguO3qoaX/1w9oHq19/xh83fjdnNk eunRBRfUuEJWUemyC/P6xD5hbS1b3Ak3EKRQV33ntCzBnh8efvIjds3OBycs1vor YoQyMfjyb5lOnJfp/bk6 =ni9Z -----END PGP SIGNATURE----- -- This publicly archived list offers a means to provide input to the OASIS Cloud Application Management for Platforms (CAMP) TC. In order to verify user consent to the Feedback License terms and to minimize spam in the list archive, subscription is required before posting. Subscribe: camp-comment-subscribe@lists.oasis-open.org Unsubscribe: camp-comment-unsubscribe@lists.oasis-open.org List help: camp-comment-help@lists.oasis-open.org List archive: http://lists.oasis-open.org/archives/camp-comment/ Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf List Guidelines: http://www.oasis-open.org/maillists/guidelines.php Committee: http://www.oasis-open.org/committees/camp Join OASIS: http://www.oasis-open.org/join/ |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]