Re: comment on TA specification

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

To me, the solution is very simple from a TP specification perspective:

   A Party is the owner of a CPP and a participant in a CPA.

   An entity may chose to define itself by one or more CPPs. If it provides
   more than one CPP, it is logically defining itself as more than one
   Party.

   The CPP may define as many capabilities as desired including specifying
   many business processes and defining separate roles and delivery
   channels for each.  It should not be necessary to discuss whether one
   complex CPP is better or worse than many simple CPPs as long as the
   Reg/Rep specification provides for both cases.

   I don't want to reopen the arguments about use of the words "Trading"
   and "Partner" but I should point out that it is illogical to say that a
   Partner owns a CPP since from the CPP perspective the owner is not a
   partner since it is not engaged with another entity.  Please use the
   term "Party" with respect to CPPs and CPAs.

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



Joaquin Miller <miller@joaquin.net> on 01/17/2001 11:25:14 PM

Please respond to Joaquin Miller <joaquin@acm.org>

To:   ebxml-tp@lists.ebxml.org, ebXML-Architecture List
      <ebxml-architecture@lists.ebxml.org>
cc:   Duane Nickull <duane@xmlglobal.com>, Martin W Sachs/Watson/IBM@IBMUS
Subject:  Re: comment on TA specification



Re: TP, CPP, CPA, ...

it seems to me that the team is drifting in the direction of a trap that
catches so many of us so often.

it will be sad if, at this early stage, workarounds are put together to
make things work.

there is still the chance to make the model fit the world.

how the world is, is clear.  being a party is one thing.  being in the role
of trader is another.  how one would like to do business with
counterparties is a third.

1. parties have organization, whereby parties are made up of parties, but
we may be able to overlook that.  a large organization may choose to be
considered as one party or as several.  counterparties need not be able to
tell from the ebXML messages what the relations among these several parties
are.

2. whether a given party will want to be seen as more than one trader, i am
not sure, but certainly it should not be the case that the data structure
forces a party--that has no reason to be, positively does not want to be
seen as more than one--forces such a party to set up to be seen as more
than one.  this will happen if we try to lump being a party in the role of
trader with how one would like to do business with counterparties.

3. certainly one party will want to have several different specification of
how they want to do business with counterparties.

...

how ever late in the game it may seem to be to make significant changes,
it will be better to feel the pain in the team now,
rather than make ebXML users work various kludges to get what they need.

...

my opinion

written to encourage team members to take their time and get it right.

i agree with marty, the issue of what is (or is not) an
"organisation/company" is too
complex and un-necessarily restrictive.

this highlights the need to clarify the use of the term "trading partner"
(or 'trading
party' if you prefer).

is it possible that a TP (whatever that stands for!) have a single CPP (and
potentially
many CPAs).  Maybe each CPP defines what the TP is???

the current glossary leaves this open.  might i suggest that this is almost
self-defining.

"A trading partner (or 'trading party' if you prefer) performs one role in
a Collaboration
Protocol Profile."

For example, if  K-Mart have a division that deals with purchasing goods
from SE Asia and
this group have a defined CPP for contract suppliers and other for ad-hoc
purchasing, then
there would be  two  TPs.  One for K-Mart/SE Asia/contract and another for
K-Mart/SE
Asia/ad-hoc.

- is that the way the TP team is thinking?


Duane Nickull wrote:

> Marty:
>
> I can forward this one,  especially since you and I have already
> discussed this in our email.
>
> Team:
>
> This comment is a valid concern.  There will be cases with larger
> enterprises whereby different divisions of the company may wish to
> express their own CPP's.  Accordingly,  this requirement for One CPP per
> Company would be prohibitive.
>
> I vote we take it out as Marty Suggests.
>
> Duane Nickull
>
> Martin W Sachs wrote:
> >
> > Klaus,
> >
> > Please forward to the TA team.
> >
> > Line 513-514:  The TP team collectively does not remember stating a
> > requirement of registering only one CPP per trading partner. Please
remove
> > this requirement.  It is overly restrictive, especially for large
> > enterprises, which may need to state various combinations and
permutations
> > of capabilities for different purposes.
> >
> > Regards,
> > Marty
> >
--
regards
tim mcgrath



Cordially,

Joaquin

................................................
Joaquin Miller
Chief Architect
Financial Systems Architects

mailto:joaquin@acm.org

San Francisco
phone: +1 (510) 336-2545
fax:   +1 (510) 336-2546
PGP Fingerprint:
CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3