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

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