Re: [ebxml-cppa] CPPA Version 1.05

[Tony Weida <rweida@hotmail.com>]

Duane,

In that case, I think we're agreed on goals!

It would be great to have an XML schema for additional party information (as
referenced by PartyRef) for version 1.1.  However, I wouldn't go so far as
saying that without it, CPPA "will not meet the minimal functional
requirements of ebXML as a whole."  The CPPA team has strong representation
from a wide variety of business integration software vendors, and yet, so
far no one else has been clamoring for it.  Since you and the core
components folks have evidently given considerable thought to this area,
perhaps one or both could help out with a suggested schema?

Thanks,
Tony

----- Original Message -----
From: "Duane Nickull" <duane@xmlglobal.com>
To: "Tony Weida" <rweida@hotmail.com>
Cc: "CPPA" <ebxml-cppa@lists.oasis-open.org>; "'Ebtwg-Ccs (list)'"
<ebtwg-ccs@lists.ebtwg.org>
Sent: Monday, January 28, 2002 5:34 PM
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>
>