The number of instances of 'may' in the WS-BPEL 2.0
spec does no tell me much. If the WS-BPEL TC really wanted to fix this problem,
I guess they could have done it (given the army of editors and the seemingly
infinite amount of time that TC had ;-). If we were
to allow the SCA specifications to liberally use lower case RFC 2119
terms, their number of instances could also reach a similar (or
higher) magnitude as that of the WS-BPEL 2.0 spec.
BTW, do we know why the WS-BPEL TC allowed using
the RFC 2119 lower-case terms with plain English semantics? If we wanted to
consider WS-BPEL 2.0 spec as a precedence, we should try to understand their
reasoning too.
-- Sanjay
From: Michael Rowley [mailto:]
Sent: Tuesday, Dec 04, 2007 17:34 PM
To: Bryan Aupperle;
Subject: RE: [opencsa-liaison]
Use of "may", "must", etc.
I agree with
.
This approach also has precedent, at least in WS-BPEL 2.0. It uses RFC
2119, but it also uses lowercase “may” in a way that has nothing to do with
interoperability of implementations that don’t implement optional features
(the way the 2119 “may” does). As an experiment, take a look at WS-BPEL 2.0
and search for “may”. You should find 171 occurances. Pick through
a few of those and imagine rewording all of them in a way that does not use
any of the 2119 terms.
Michael
From: Bryan
Aupperle [mailto:]
Sent: Tuesday, December 04, 2007 3:42
PM
To:
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
+1 919-254-7508 (T/L
444-7508)
Internet Address:
"Patil,
Sanjay" <>
12/04/2007 10:34
AM
To
<>,
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.
, 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
>
