Re: [ebxml-cppa] CPPA Version 1.05

[Duane Nickull <duane@xmlglobal.com>]

Marty:

Thanks for the clarification.  THis was my understanding too.  I think
we are all clear on this.

That being said,  I stil have major issues with PartyID and PartyRef
(not PartyInfo which I mistakenly indicated in my earlier emails).

Duane

Martin W Sachs wrote:
> 
> Duane,
> 
> This discussion is getting tripped up on terminology.  Please keep in mind:
> 
> PartyId is the party's well known identifier in whatever system we choose
> to specify (e.g. DUNS). Your issues with PartyId are separate from your
> other issues.
> 
> PartyRef is the element that points to the external information about the
> Party that you are having trouble with. It has nothing to do with the
> issues around PartyId.
> 
> PartyInfo is the root element for most of the information in the CPP. It
> has nothing to do with your issues.
> 
> 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
> *************************************************************************************
> 
> Duane Nickull <duane@xmlglobal.com> on 01/28/2002 05:34:32 PM
> 
> To:    Tony Weida <rweida@hotmail.com>
> cc:    CPPA <ebxml-cppa@lists.oasis-open.org>, "'Ebtwg-Ccs (list)'"
>        <ebtwg-ccs@lists.ebtwg.org>
> Subject:    Re: [ebxml-cppa] CPPA Version 1.05
> 
> Tony Weida wrote:
> > You're addressing the wrong audience in your campaign against DUNS
> > numbers -- please remember that the CPPA spec doesn't require or
> recommend
> > them in any way whatsoever.
> >>>>>>>>>>
> Tony:
> 
> My fight is not against DUNS.  It is about the mechnism in general.  I
> think it needs to be thought through really well.  At the first glance,
> it appears extremely simple, however once you start working with it
> under the hood,  there are issues.
> 
> > The spec simply enables a CPP owner to include a set of identifiers of
> their
> > own choice.
> >>>>>>>>.
> This is noble and needed.  IT is the mechanism itself I have some
> questions about.
> 
> 1.  In the Schema, there is no enumerated list of values.  The schema
> simply says:
> 
> <attribute name="type" type="tns:non-empty-string"/>
> 
> therefore, I can already see a problem.  If I were to assign my company
> its' own ID as you have stated is possible (Re: you wrote "If the DUNS
> number doesn't suit you, simply ignore it and use one or more of the
> other identifiers."), and I choose to use Duanes' Unique Numbering
> System, I may end up with something like this:
> 
> <tp:PartyId tp:type="DUNS">123456789</tp:PartyId>
> 
> which may conflict with another persons ID if
> 
> <tp:PartyId tp:type="DUNS">123456789</tp:PartyId>
> 
> becuase their "DUNS" means "Dun and Bradstreet".
> 
> I suggest that we reword this spec to permit specific enumerated  values
> which are semantically meaningful.  IF we do use "DUNS", and it means
> "Dun and BradStreet", then lets' do this properly.
> 
> 2.  The second technical issue is that I need more information about the
> Trading PArtner than just a unique ID.  That can be done presumably via
> the link to PartyInfo:
> 
> <tp:PartyRef xlink:href="http://CompanyA.com/about.html" />
> 
> This is a separate problem from the ID one and I will address this
> separately.
> 
> My main concern about the DUNS is that there is no mechanism to make
> sure that we have a way to track the DUNS value to an actual company
> programatically (via a DUNS lookup registry or something similar).
> 
> 3.  Regarding the separate issue of the PartyInfo link:
> 
> This needs to also have a type="something" that will give me information
> so I can retrieve the values I need electronically.  The COre COmponents
> team is relying on the fact that one can obtain the geopolitical
> information during the Design and Discovery Phases.  If we use the XML,
> which I fully agree is possible using the existing structure,  we end up
> with something like this:
> 
> <tp:PartyRef xlink:href="http://CompanyA.com/about.xml"/>
> 
> THis is still not enough information for me to write code to retrieve
> the information I need.  For example,  if I write a program to get this
> information and want to parse out the country code, what is the path to
> that code?  Is that code an ISO country code?
> 
> What I suggest we need is a way to declare what XML format the
> information is expressed in.  I think that the CPP/A team should also
> provide at least one default PartyInfo format in XML that also contains
> the Minimal set of information to allow the context drivers to be
> gathered.  Anything less and I think that the CPP/A will not meet the
> minimal functional requirements of ebXML as a whole.
> 
> That being said,  the CPP/A is very close.  Just these two minor things
> and it is there.
> 
> > (If you have issues with DUNS numbers per se, you should really take that
> up
> > with D&B and / or the companies that choose to use DUNS numbers.)
> >>>>>>>>
> 
> Okay - the cats out of the bag.  I once had a terible experience trying
> to get a DUNS number.  That is not my main contention.  It is the
> mechanism itself that relies on the fact that DUNS means what you think
> it is and allows other to verify and find out more. ;-)
> 
> Duane
> 
> CTO, XML Global Technologies
> ****************************
> Transformation - http://www.xmlglobal.com/prod/foundation/
> ebXML Central - http://www.xmlglobal.com/prod/central/
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>

-- 
CTO, XML Global Technologies
****************************
Transformation - http://www.xmlglobal.com/prod/foundation/
ebXML Central - http://www.xmlglobal.com/prod/central/