[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-msg] Messaging Spec v1.092
I also am absolutely not anti-CPA -- I am very much PRO CPA. I just don't want to limit Messaging to ONLY CPA. I think it is very possible to conduct messaging without a prior agreement (Credit Card number for CPAId, url for PartyId, etc.). Yes, the MessageHeader might have been too bloated, but now it is too lean. We need to decide what might be defaults (retries/retryInterval/persistDuration) and what might need to be in MessageHeader to allow spontaneous eCommerce and what Errors might we be able to work around so messages can go through with only a warning rather than stop processing. Regards, David. -----Original Message----- From: Burdett, David [mailto:david.burdett@commerceone.com] Sent: Monday, January 07, 2002 10:48 AM To: 'Dale Moberg'; David Fischer; Martin W Sachs; Jacques Durand Cc: Arvola Chan; ebXML Msg; Ian. C. Jones (E-mail) Subject: RE: [ebxml-msg] Messaging Spec v1.092 Dale you said ... >>>DM>I think you would have to have a coherent basis for deciding what was to be in the header and what what just configuration no matter whether there was a CPA or not. You simply forget that before we had even introduced CPA, Drummond and many others were strongly arguing that David Burdett's list of headers was severely bloated, or, with reversed bias, comprehensive. The CPA stuff emerged as a _solution_ to this problem. Those who forget history...<<< What I think we have really done is exchange one form or complexity, "Putting the information in the header" for another "Putting the information in a separate agreement which must be pre-negotiatied". If a problem is complex, and reliable messaging and security are complex, then the solution is necessarily complex. Shuffling the data from the header to the CPA has not made the problem go away. David PS I am not anti-CPA, I just want them to be used in the right way. -----Original Message----- From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com] Sent: Monday, January 07, 2002 8:16 AM To: David Fischer; Martin W Sachs; Jacques Durand Cc: Arvola Chan; ebXML Msg; Ian. C. Jones (E-mail) Subject: RE: [ebxml-msg] Messaging Spec v1.092 See comments in line. But with this initial premise: the "independence" that we seek in each ebxml specifications is not like political independence or sovereignity but more like logical independence. The idea of logical independence is that either including or omitting some item is consistent with some target module. For example, the parallel postulate is independent of euclidean geometry core axions because it can be consistently added to them or consistently omitted from them. Thus, I do not take independence to mean that Messaging stuff can be used with or without CPPA stuff. Previously, people have commented that Messaging clearly can be used without CPPA stuff. Can it be used with it? I think David wants to make it difficult to use CPPA with it. DF= David Fischer DF>I disagree. If the specs were truly loosely coupled then we would not have discussions concerning discrepancies between the header fields and the CPA. Those discussions are concerned with using CPA _with_ Messaging-- to make certain Messaging can work the way it is specified and people _can_ use a CPA. DF> Errors concerning such discrepancies would be implementation dependant. Well, make them so. I wonder how that will promote interoperability. DF>We would not worry about aligning Messaging and CPA. DM> So the CPA can fail to specify parameters needed by a CPA? And they will "work" together? The alignment is mainly of CPA with Messaging, not the other way around. DF>We would not have continual problems with having to remove fields from the Messaging headers because they are already specified in the CPA (in fact, many fields would exist both places). DM>I think you would have to have a coherent basis for deciding what was to be in the header and what what just configuration no matter whether there was a CPA or not. You simply forget that before we had even introduced CPA, Drummond and many others were strongly arguing that David Burdett's list of headers was severely bloated, or, with reversed bias, comprehensive. The CPA stuff emerged as a _solution_ to this problem Those who forget history... Several fields do exist in both, and there is a mechanism for indicating that header values rule. Anytime a consensus forms on putting something in the header, it can be adopted. DF>We even voted at the last F2F that there MUST be an agreement in place -- no allowance for spontaneous eCommerce. There has been constant discussion that there MUST be either a CPA or a "virtual CPA", which simply means a database containing all the CPA fields and structures even though there may not be an actual XML document anywhere. Quotes from the spec to the contrary are simply my lack of diligence in removing them since the last F2F. DM> David, now you are drifting away from independence and into something else. Marty has explained that use of agreements will become consistent with use of CPA templates etc. This is a provisional state of development that we do not have an automatic negotiation protocol done yet. Also, there is a "solution" that already develops this angle (SOAP+UDDI+WSDL). Why should we reinvent this? DF> If we could move back to a time when we did allow non-agreement (with or without CPA) type eCommerce, then that would remove my objection -- but I don't think that is where we are now. DM>So, the objection really isn't to CPA stuff? OK moving on... DF>Our original charter was to focus on the SME needs in eCommerce. DM> I understood the interest to be in not ignoring the SME needs, not focus on them. If the SMEs cannot talk to non-SMEs the spec would have limited value. Presumably, the nonSMEs have more complex environments while SMEs can get buy with a very restricted subset. DF>I would argue the SME's need something more akin to B2C rather than traditional B2B (I don't mean Web based but I do mean spontaneous). Possibly. I am very uncertain what the SME market needs or wants in detail. For all we know, they want it all to come in on their fax machine. Where are the detailed, empirically supported, studies of this alleged market and its interest in automating business processes? DF> My objection is that our (very good) system is largely a rehash of what has gone before (and maybe somewhat of an improvement) but it does NOT adequately address the needs of SME's. Actually, I agree with this. But I would think it would be a good reason for abstaining from lack of interest, rather than vote against. DM> I would like to see a clear definition of these needs, backed up by extensive informed statistical surveys (that is, not marketing or analyst group stuff) to show that these are the needs of these SMEs. We never had this information, and we still don't. DF> Now, someone else please take the SOAP box ;-) DM> This comment intentionally blank. ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- 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