ebxml-msg — archive

RE: [ebxml-msg] Messaging Spec v1.092

From: System
To: [email protected]
Date: Sun, 06 Jan 2002 18:55:00 -0000

David, Some comments below. 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 ************************************************************************************* "David Fischer" <[email protected]> on 01/06/2002 05:23:55 PM To: Martin W Sachs/Watson/IBM@IBMUS, "Jacques Durand" <[email protected]> cc: "Arvola Chan" <[email protected]>, "ebXML Msg" <[email protected]>, "Ian. C. Jones \(E-mail\)" <[email protected]> Subject: RE: [ebxml-msg] Messaging Spec v1.092 I disagree. If the specs were truly loosely coupled then we would not have discussions concerning discrepancies between the header fields and the CPA. Errors concerning such discrepancies would be implementation dependant. We would not worry about aligning Messaging and CPA. 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). MWS: You are missing the point, David. Everything in the CPA is there for a reason - to ensure that the two parties are configured compatibly. The configuration information has to be in both parties' systems or they cannot communicate. You cannot avoid that requirement. The only question is whether the two parties get together on a a single configuration description or separately type in the information through their own GUIs. We even voted at the last F2F that there MUST be an agreement in place -- no allowance for spontaneous eCommerce. MWS: CPA does not preclude spontaneous eCommerce. Eventually there will be an automated composition/negotiation process in place that will allow the configuration setup to be fast enough for spontaneous eCommerce. The CPPA team is taking the first steps toward this now. Lack of a CPA is what precludes spontaneous eCommerce because that guarantees that the relationship has to be configured manually. 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. MWS: See my first comment above. You cannot avoid the runtime database unless you think that you can legislate a single software and middleware configuration that everyone is required to use on pain of ... 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. MWS: Non-agreement means non-communication if there are any configuration variables, and today there are plenty. Our original charter was to focus on the SME needs in eCommerce. 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). 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. MWS: If you want extreme simplicity, SOAP and WSDL have already done it, so maybe we should fold up shop and let Web Services take over. Now, someone else please take the SOAP box ;-). Regards, David Fischer Drummond Group.