[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-cppa] CPPA Version 1.05
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/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC