[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-cppa] [ebxml-msg] Attributes specified in both the messageand the CPA
Rejoinders below (MWS2:) ************************************************************************************* 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 ************************************************************************************* Dan Weinreb <dlw@exceloncorp.com> on 11/01/2001 10:47:05 PM Please respond to "Dan Weinreb" <dlw@exceloncorp.com> To: Martin W Sachs/Watson/IBM@IBMUS cc: ebxml-msg@lists.oasis-open.org, ebxml-cppa@lists.oasis-open.org Subject: Re: [ebxml-cppa] [ebxml-msg] Attributes specified in both the message and the CPA Date: Thu, 1 Nov 2001 16:21:20 -0500 From: "Martin W Sachs" <mwsachs@us.ibm.com> For version 1.1, the F2F ended up breaking out 6 or 8 separate Boolean parameters that together define the delivery semantics. 6 or 8? Oh, come on, gimme a break... The only breaking out we did was to separate retry/ack from duplicate elimination to create the four possibilities BestEffort, AtLeastOnce, AtMostOnce, and OnceAndOnlyOnce. You may be thinking of a table with 8 *rows*, due to *3* booleans. The reason there were 3 booleans in the table was to distinguish between Ack and DeliveryReceipt and/or between hop-by-hop Ack and end-to-end Ack, a distinction that was *already* in place before the F2F meeting. MWS2: Right. I was thinking of the 8 rows. Mea culpa. The CPA will have to agre with however this redefinition comes out in the MS spec. This point applies to all the following paragraphs. Yes, I agree that the CPA will have to agree with this. MWS: I think there is a problem with interpreting the word "idempotent". Formally, idempotent means that repeating the function will produce the same result and therefore it is not necessary to eliminate duplicates, which I think is what you are saying here. The problem (which I think we discussed at the F2F) is that "idempotency" in our context means "test for duplicates" (a common misuse of the word "idempotency"). We should say "eliminate duplicates", not "idempotency". I agree. The word "idempotent" has been around for a very long time with the formal meaning that you give above, and we should not try to redefine it. MWS: I agree: The problem with splitting delivery semantics into a bunch of boolean parameters means that some combinations are meaningless and in other cases, settings of two different parameters to "yes" is a redundancy. I see it the other way: by splitting one boolean into two orthogonal booleans, we get four combinations, each of which is meaningful and potentially valuable. The current CPA, in contrast, has booleans for "idempotency" (sic) and "reliable", which are not orthogonal, hence the meaningless combinations. MWS2: I agree. However you are looking at the V 1.0 CPA spec. We all understand that the CPA spec will have to be put in sync with the redefinition of delivery semantics. -- Dan
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC