below in <ba> ... </ba>
Bryan Aupperle, Ph.D.
STSM, WebSphere Enterprise Platform Software Solution Architect
Research Triangle Park, NC
+1 919-254-7508 (T/L 444-7508)
Internet Address:
Jeff Mischkinsky <>
12/04/2007 08:59 PM
To
Bryan Aupperle/Raleigh/IBM@IBMUS
cc
Subject
Re: [opencsa-liaison] Use of "may",
"must", etc.
hi,
On Dec 04, 2007, at 12:41 PM, Bryan Aupperle wrote:
>
> A couple of examples we have come across so far:
>
> Service interfaces may be annotated to specify whether their
> contract is conversational, as described in the Assembly
> Specification [ASSEMBLY] using the @Conversational annotation.
> Note for C++, annotations are currently anticipated to be processed
> by tools so annotated source, in and of itself, does not force any
> behavior on anything other than a annotation processor. The
> conversational intent in the SCDL is what is meaningful. Thus
use
> of "MAY" is not appropriate here. Replacing "may"
with "can" is
> not grammatically correct.
>
> The data exchange semantics for calls to local services is by-
> reference. This means that code must be written with the knowledge
> that changes made to parameters (other than simple types) by either
> the client or the provider of the service can be seen by the
other.
> This is not really a compliance point (I would not expect a test
> for it) but clearly guidance to someone reading the specification
> intending to implement components. Removal or "must"
is awkward
> and other options are wordier.
How about "This means that code has to be written with ... "
- at
least in this instance its easy.
I'm puzzled by the first example. Why isn't this the use of may, in
the RFC sense? Is the wording saying that the use of @Conversational
is meaningless? If not then i don't see why RFC 2119 doesn't apply.
If so, then why say anything about it. I am confused.
cheers,
jeff
<ba> The first example is related to the question
of conformance targets. We have not yet settled on this, and that
may be the ultimate solution for this particular instance. I was
trying to point out that the are cases where we want to expression something
being allowed that is not strictly a compliance point.
Your wording certainly works for the second case but
as I pointed out is wordier (using two words where one suffices), but if
that is the way we need to proceed, I understand. </ba>
>
>
>
> Bryan Aupperle, Ph.D.
> STSM, WebSphere Enterprise Platform Software Solution Architect
> Master Inventor
>
> Research Triangle Park, NC
> +1 919-254-7508 (T/L 444-7508)
> Internet Address:
>
>
> "Patil, Sanjay" <>
> 12/04/2007 10:34 AM
>
> To
> <>, Bryan Aupperle/Raleigh/IBM@IBMUS
> cc
> <>
> Subject
> RE: [opencsa-liaison] Use of "may", "must", etc.
>
>
>
>
>
>
> If we did that (that is treat the terms in lower-case differently
from
> their upper-case version), then our specs can not claim full
> compliance
> with RFC 2119, since RFC 2119 does not differentiate the key words
> based
> on their case. The problem with invoking RFC 2119 only for upper-case
> keywords would be that - we might be upsetting a lot of readers out
> there who have by now started expecting a full compliance with RFC
> 2119.
>
> Bryan, could you give us one or two examples of the awkwardness you
> faced while substituting the RFC terms? Perhaps we can just
> identify the
> common situations of such awkwardness and try to come up with some
> alternative terms that can be uniformly used by all the SCA specs.
>
> -- Sanjay
>
> >
