Re: CPP/CPA specification clarification

[Eric Chiu <echiu@imservice.com>]

Marty,

Thanks for your help. I'd like to get further details if possible...
questions and comments below. If you can confirm or
correct my assumptions, I would appreciate it.

> MWS:  The CPP/CPA specifciation does not provide a business document set.
> The Core Components team is attempting to define rules for creating
> document components that can be composed into documents.

ETC: So the CPP/CPA specification defines the constraints for writing CPPs
and CPAs, but does not actually define specific CPPs and CPAs. It leaves the
task of defining generic CPPs for the CC spec, and specific implementations
of CPPs
and CPAs to actual developers of the system. So CPP/CPA spec is like
a high-level overview of what should be in a specific CPP/CPA?

> MWS:  The CPP is a document that defines the owning party's IT
> characteristics and points to the collaborative business processes that
> it supports.  The CPA is a document that defines the agreed IT
> characteristics under which a pair of parties will exchange messages and
> points to the agreed collaborative process.  Document types (e.g. schemas)
> are identified in the collaborative process definition (Process
> Specification
> document.)

ETC: So to use an analogy, CPP is like a public website that I can query to
check on
the corporate profile of my trading partner, with basic information on what
goods and
service the company offers/wants. I'll have to authenticate, and then I'll
be shown an
CPA, which is a secured extranet, with actual forms for me to purchase
goods/services.
Then I can exchange messages on trades (presumably using ebXML
messaging).....

> MWS: It does not piggyback on X12.  I'm not even sure what that means.
> The messages exchanged between the two parties can be EDI messages as
> well as XML messages.  There is no specific dependence on the ebXML
> registry or any registry.  However the partner discovery process is
> very important to e-business.  Normally you should expect to pull
> a partner's CPP from a repository.  The CPA is effectively private
> to two parties and will probably not be kept in a repository.

ETC: Yes, I presume a "Yellow Pages" of goods and services will evolve to
assist in
the partner discovery (there were references to this in the requirements and
tech arch
specs). Though there is no logical dependency of the CPP/CPA spec on
Registry/Repository specs,
there are frequent references between specs. I suspect real world
applications will adapt
both or none. Do it make sense to create ebXML-compliant CPP, then put it
into a non-ebXML compliant repository?

> MWS:  Yes, if a CPP or CPA is transferred in a message, it is the
> payload. However the CPP and CPA are NOT exchanged in the messages
> which two parties exchange in performing a business process.  They
> may be sent in messages when obtained from a repository or when
> negotiating the details of a CPA.

ETC: what are alternative non -messaging methods of transferring CPP/CPA
content? Why "may" instead of "should" in this case of querying CPA from a
repository?

> MWS:  Section 6 of the specification provides a good description of
> CPP-CPA usage.  For an overall view of the ebXML goals and architecture,
> get
> the requirements and technical-architecture specifications from the
> ebXML website.

ETC: You're right, section 7 of CPP/CPA spec provide a good overview of
usage
at a high level, step-by-step. I think I need to have a prototype to
visualize this better.
It's not technical, but there are a number of possible permutations in the
process,
if you explore all the branches.