That's
another "option"...
I
agree many times we abuse these keywords
(instead of saying "a message MAY have this or that"
we
probably should say "a Sender MAY insert this or that in a
message"
and
state explicitly after, that "a Receiver MUST be able to process all features of
a message"
i.e.
use these keywords only directly related to an
implementation.
let me
think more about it.
I know
we had similar problem in ebMS...
Jacques
-----Original Message-----
From: Martin Sachs
[mailto:]
Sent: Sunday, September 28, 2003
5:02 PM
To: Jacques Durand
Cc: ;
wsrm
Subject: RE: [wsrm] Optional Presence vs. required
support
Importance: Low
It would be better to
completely avoid using the terms "optional" and "may" when the context is not
that intended by RFC2119. Avoiding the terms will provide a much
stronger assurance against misinterpretation than including a statement that
might be overlooked, in the conformance section. English has other words
and phraseology that can be used where the semantics are "may" or "optional"
but support is nonetheless required, e.g., the 4th paragraph of (1)
below. In the CPPA specification, we completely avoided using the terms
"optional" and "may" when the sense is not as intended by RFC2119.
I
also want to remind everyone that RFC2119 does not REQUIRE the use of upper
case when its keywords are used in the RFC2119 sense. That is a common
practice that but it's not normative. Therefore, use of upper case when
the context is that intended by RFC2119 still requires an explanation in the
conformance section and that explanation might be
overlooked.
Regards,
Marty
At 05:01 PM 9/26/2003 -0700,
Jacques Durand wrote:
Tom:
The following might help to clarify the notion of
conformance in the spec:
1. how developers
should interpret RFC2119 keywords
(RFC2119 is coming
short of avoiding ambiguous interpretation):
(Extracted from the ebMS conformance section: )
"[an implementation is conforming if] It complies with the following
interpretation
of the keywords OPTIONAL and
MAY: When these keywords apply to the behavior of the implementation,
the implementation is free to support these behaviors or not, as meant in
[RFC2119].
When these keywords apply to
message contents relevant to a module of features, a conforming
implementation of such a module MUST be capable of processing these optional
message contents according to the described semantics."
I find these general terms clear enough, and avoiding the drawback of
reasoning in terms
of "Service" vs. "client" , which
may become tricky (as the service side may also
initiate messages)
2. Adding a
Conformance clause section in the spec,
gives the
flexibility to describe [possibly several] levels or profiles of
conformance,
and their interoperability
relationship.
In other words, when we use MUST,
SHOULD, etc., these should be understood
as being
within the scope of a feature , i.e. "if feature XYZ is used..."
Then in the conformance clause we can make higher-level
statements about which features
MUST be supported in
order to conform [to a profile].
Regards,
Jacques
-----Original
Message-----
From: Tom Rutt [mailto:]
Sent: Friday, September 26, 2003 2:25 PM
To:
wsrm
Subject: [wsrm] Optional Presence vs. required
support
We need to get some important discussion
on the conformance aspects of
our protocol.
We have several syntactic mechanics which have the
presence of a
subelement in a header
(or an attrbibute of some header subelement) signalling to
the receiver
that a particular
protocol mechanism is in use.
Interoperability would be greatly increased if all our protocol
mechanisms are requred
to be
supported by all RMP (at least on the service instance end).
The Client of the service would be the one always
choosing whether the
protocol feature is
used.
I realize that this global interop goal is
probably not attainable (not
everyone needs
ordering),
but we should limit the number features
which are not required (i.e,
optionsal) for
conformance.
Anyway, we need to use careful
wording in the protocol syntax
descriptions
when an element (or attribute) is specified as "able to be
not present". In each case we need to clarify the
support
required for conformance claims.
I suggest we could have conformance based on
feature:
eg:
-
acknowledgment conformance class
- acnlowledged
duplicate conformance class
- acknolwedged
duplicatate elimination and ordered delivery conformance
class
Now the next question is if we need
to further parameterize our
conformance claims
by
the RM-Reply patterns supported by an
implementation:
- response reply pattern
- callback reply pattern
- poll
reply pattern
And then again we have the support
for request/response WSDL operation
type.
Is
this going to be another conformance point
parameter.
Thus we have 3 by 3 by 2 conformance
matrix. How many of those 3D
matrix cells do
we
want to give separate names to?
Tom Rutt
WSRM Chair
--
----------------------------------------------------
Tom
Rutt
email: ;
Tel:
+1 732 801 5744 Fax:
+1 732 774 5133
To unsubscribe
from this mailing list (and be removed from the roster of the OASIS TC), go
to http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.
*************************************
Martin
Sachs
standards architect
Cyclone
Commerce
