ebxml-tp message

OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

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.


 -----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.


 Here are some initial responses to your comments, embedded below.



 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
 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

 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

 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
 of 1 CPP is a problem.  Presumably a large enterprise might want different
 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
 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


 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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC