ebxml-architecture 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: [Fwd: comment on TA specification]

Forwaded as per Marty's wish

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

   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.



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

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
many CPAs).  Maybe each CPP defines what the TP is???

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

"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

- 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
> > this requirement.  It is overly restrictive, especially for large
> > enterprises, which may need to state various combinations and
> > of capabilities for different purposes.
> >
> > Regards,
> > Marty
> >
tim mcgrath



Joaquin Miller
Chief Architect
Financial Systems Architects


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

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

Powered by eList eXpress LLC