Folks,
OK, I'll bite on the challenge set by
Bryan for these two cases, in the full and certain knowledge that showing
a solution for
just these two will not address the
wider sea of cases spread across all the SCA specifications.
1)
I'd take this as being normative in
the first instance. It is stating something testable - that a C++
service interface has an optional
annotation, that, when present, indicates
that the contract defined by the interface is conversational. The
target for the normative
statement is the interface document
itself:
"Service interfaces MAY be annotated
to specify whether their contract is conversational, as described in the
Assembly Specification [ASSEMBLY],
using the @Conversational annotation."
...if you don't want the statement to be normative, then
I would cast it as follows:
"A @Conversational annotation is optionally applied
to a C++ Service interface to indicate that the service contract is conversational,
as
described in the SCA Assembly specification [ASSEMBLY]."
2)
I'm assuming that there is nothing normative
here.
"The data exchange semantics for
calls to local services is by-reference. This means that code
needs to 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."
I think it is perfectly possible to
write meaningful text without using RFC 2119 terms. Whether we want
to spend the time doing this wordsmithing across
the specs is the issue.
Yours, Mike.
Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
Email:
Bryan Aupperle <>
04/12/2007 20:41
To
cc
Subject
RE: [opencsa-liaison] Use of "may",
"must", etc.
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.
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
>
