Subject: RE: initial draft of CPP-CPA Specification
As to the "one and only one CPP per company" in the Technical Architecture document, I do not remember as well that this was a requirement that was asked by the TPA Team. /Stefano » -----Original Message----- » From: Martin W Sachs [mailto:mwsachs@us.ibm.com] » Sent: 17 January 2001 16:18 » To: Duane Nickull » Cc: ebxml-tp@lists.ebxml.org » Subject: Re: initial draft of CPP-CPA Specification » » » » Comments from Duane Nickull appended. » » Duane, » » Here are some initial responses to your comments, embedded 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 » ****************************************************************** » ******************* » » » » Duane Nickull <duane@xmlglobal.com> on 01/16/2001 06:46:09 PM » » To: Martin W Sachs/Watson/IBM@IBMUS » cc: » Subject: Re: initial draft of CPP-CPA Specification » » » » Hello Marty: » » I have read most of the spec and I wanted to start asking a few » questions: » » 1. Line 8 ... » » You mention TPP and the relationship of TPP to CPP and CPA. IS this » team going to define a TPP syntax too or will that be wrapped into the » CPP document? » » MWS: The mentions of TPP and TPA in the first paragraph are to satisfy » a perceived desire on the part of ebXML management to connect what we » are doing to the traditional term "trading partner". At this time, » function beyond the CPP and CPA requirements is outside our scope. » » From a business use case, if I want to find out what a » business party can do, I need to have a document which defines a high » level wrapper with things like NAME, ADDRESS, CONTACT, etc. » » MWS: Our current thinking is that this information will be found by » following the pointer in <PArtyDetails> » » I assume » that is still the TPP document. Inside the TPP, there is the CPP which » defines the business party's capabilities (transport mechnisms, business » processes available for engagement in, security etc). Out of that, » there is a process which allows the two parties to dynamically negotiate » and generate a CPA for entring into a specific transaction. » » To begin with, please let me know if I have understood this correctly. » » MWS: You have understood this correctly. the actual process of composing » and negotiating the CPA is outside our scope. It is viewed as a business » process and presumably someone can make money by implementing » that process. » » 2. Appendix A » » In your example CPP document, you have only one element of » CollaborationProtocol for a process marked "... Purchasing.xml". It » states earlier that you may have one or more <CollaborationProtocol> » elements per CPP so I am assuming that for example purposes only, the » company that presumably owns this CPP has only one business process but » is free to add additional <CollaborationProtocol> elements to its' CPP » to support additional Business Processes. » » MWS: correct » » Out of the preceding comment, I question whether or not such a company » would want to define its' Message encoding, Transport security et al, » once for all processes. I understand (I think) the intent that the » company will publish the CPP then the CPA will be negotiated out of a » list of ALL the possibilities and a CPA creation will guide the » transaction. What if the company wants to define some capabilities that » only apply to one if several supported business processes? » » MWS: A distinct delivery channel can be associated with each supported » business process. Therefore different sets of capabilities can be » provided for each supported process. » » Do they have » to create a second CPP form? Are two or more CPP's per company » acceptable? » » MWS: the ebXML Technical Architecture document currently states that » each party can have only one CPP. I don't recall whether this requirement » came from our team originally. Given that we can define multiple processes » with different capabilities in a single CPP, it is't clear that the » limitation » of 1 CPP is a problem. Presumably a large enterprise might want different » CPPs » for different parts of the business. As long as those parts can appear as » distinct parties from the repository viewpoint, that should be OK. If » anyone » wants to open the issue of multiple CPPs per party, we can » discuss this and » then resolve it with Technical Architecture. » » 3. Line 1159 - there is a missing ">" between "...duns" and » » » "12345678...". » » MWS: I don't think so. That whole string is supposed to be the URI as a » #PCDATA field. » » 4. Line 1241 to 1245 » » Just a note: Each Business process will have its' own Globally unique » Identifier. We are probably favouring the UDDI attribute of » 'UID="someValue"' to associate the GUID with the document. » » MWS: The URI forumlation is supposed to be able to cover any » kind of party » ID. Doesn't the existing PartyId element cover this case? » » 5. I look forward to see how these constructs are mapped to the ebXML » message headers. » » MWS: Yes, we are all awaiting the ultimate version of the TRP spec :-) » » » The work looks good and it looks like a lot of thought has gone into it » so far. I am impressed and pleased to be able to read this work. » » MWS: thank you very much. » » Duane Nickull » » » »
Powered by
eList eXpress LLC