Re: initial draft of CPP-CPA Specification

[Martin W Sachs <mwsachs@us.ibm.com>]

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