[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-msg] CPA & MS overriding parameters
Marty, I don't know where the TC went today with this, but my comments are inlined. I may be missing some important ideas, in which case, I look forward to getting educated. Regards, -Suresh -----Original Message----- From: Martin W Sachs [mailto:mwsachs@us.ibm.com] Sent: Wednesday, November 14, 2001 8:02 AM To: Damodaran, Suresh Cc: 'ebxml-msg@lists.oasis-open.org'; ebxml-cppa@lists.oasis-open.org Subject: Re: [ebxml-msg] CPA & MS overriding parameters Suresh, I have the benefit of not having spent 3 hours on the phone yesterday. <sd> I would say that is a real benefit:-) </sd> The CPA documents policy agreed to by two parties. If one party can override information in the CPA, that party is violating the agreement. <sd> Absolutely. The flip side is, if both parties agree that some parts of the agreement MAY be overridden under certain situations, that also is reasonable? </sd> The CPA can identify that parameters that both parties agree can be overridden. But then, why bother putting them in the CPA at all? Once you decide that the MS can override the CPA, there is no reason to put those parameters in the CPA. Let them just be dynamic parameters. <sd> The parameters that can be overridden are in CPA also because in some cases parties may decide that these MUST not be overridden, and state so in the policy (we may not have such a mechanism in CPA, but the CPA TC may consider having it) <sd/> I don't understand the point about the CPA and MS work proceeding independently. That would imply that no coordination is needed. Since the main job of the CPA is to provide configuration information to the MSH, it makes absolutely no sense to let them get out of sync. <sd> You are absolutely right. They should not get out of synch. But the discussion of where a parameter should be placed not be allowed to tie up the discussion of either TC either. The same parameter could be in both message header or CPA, except that whether it MAY be overridden should also be in the CPA. </sd> Regards, Marty **************************************************************************** ********* 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 **************************************************************************** ********* "Damodaran, Suresh" <Suresh_Damodaran@stercomm.com> on 11/13/2001 06:28:59 PM To: "'ebxml-msg@lists.oasis-open.org'" <ebxml-msg@lists.oasis-open.org> cc: Subject: [ebxml-msg] CPA & MS overriding parameters Hi All, After hearing the discussion today over the phone on CPA parameters overriding MS parameters, I have to make the following case (a possible compromise): If CPA is indeed a document that captures policy, then CPA may also specify which MS parameters that the parties to the CPA wants to override using the values in the CPA (the duplication serves as a check, if necessary). This allows for both business cases where CPA values are never overridden, and the other business case of MSG overriding some values. The advantage of this approach is that CPA work can proceed independent of MS and vice versa. We may think of making OPTIONAL any parameter that must also appear in CPA. We may be even able to create MSH and CPA independently. The only issue now is to consider what the default behavior is. Since there are only a few parameters that are under discussion, perhaps letting MS override CPA might be a good default. I can live with the other way around also. Just my 2 cents worth of wisdom after cramping my neck listening in for 3 hours of back and forth arguments and votes. Regards, -Suresh ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC