Some comments below, MWS:
*************************************************************************************
Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287; IBM tie line 863-7287
Notes address: Martin W Sachs/Watson/IBM
Internet address: mwsachs @ us.ibm.com
*************************************************************************************
David Fischer <david@drummondgroup.com> on 12/03/2001 09:43:28 PM
To: Arvola Chan <arvola@tibco.com>, ebXML Msg
<ebxml-msg@lists.oasis-open.org>
cc:
Subject: RE: [ebxml-msg] Minutes 12/03/01 - Voting Meeting
Arvola,
If AckRequested is *true* in the CPA, then does the AckRequested element
have to
appear? If it MUST appear, then why have it in the CPA? I think the
Receiving
MSH must send an Acknowledgment in this case even if AckRequested does not
appear. Actually, I would prefer that AckRequested MUST NOT appear if the
CPA
says *true* or *false*.
MWS: I agree with the last statement.
If AckRequested is *perMessage* in the CPA, then what happens if the
AckRequested element does not appear? The spec says this means no
Acknowledgment. The default then is *false* if the CPA says *perMessage*.
MWS: This is a programming error. The MSH should do nothing except forward
an error indication upward to the middleware/software layer that cares
about it.
I think we should not have multiple rules about *perMessage*. If a default
is
provided in one case, then it should work the same in all cases. Since the
absence of an Acknowledgment element means *false* then the absence of
duplicateElimination should also mean *false* and the absence of a signed
attribute should mean *false* (or in all cases it means take the default).
MWS: The MSH SHALL not guess. There are valid defaults, such as
specifying
the value of Ackrequested in the CPA and omitting the element from the
message.
Defaults must not be used to paper over software errors. That can cause
untold
harm at both ends.
David.