OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

camp-comment message

[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


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:
Hash: SHA1


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 Durusau
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
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/


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]