Title: RE: [wsrm] Optional Presence vs. required support
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.
