Re: comment on TA specification

[Joaquin Miller <miller@joaquin.net>]

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