[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC