[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-cppa] CPPA version 1.10
again, it wasn't my intent that the ssn or ein be used, but it was an example of an authority that had an identification scheme with a managed namespace. It was just an example. The point is that D&B has such a namespace and if they would simply register a URN scheme with IANA then the issue would be moot. In the absense of a URI/URN scheme we and many before us have resorted to code sets (like 'DUNS') that in reality are just another value in a namespace which is not identified. Maybe OASIS should simply use its namespace (the regrep team maybe) to establish a branch that could be used to assign identifiers for codes like 'DUNS'... e.g. urn:oasis-open.org:tc:regrep:foriegn-namespaces:duns which we could use as values for the 'type' attribute and then make the 'type' attribute of type xsi:anyURI and be done with it. Cheers, Chris Duane Nickull wrote: > In reality, I think that most people would be very reluctant to give > out either or these 2 numbers however, the concept is good. > > Duane > > Martin W Sachs wrote: > >>I agree regarding social security number. However Chris also mentioned >>taxpayer ID number. I believe that UDDI also provides for identification >>by taxpayer ID. For a business, that isn't a problem regarding SSN. Of >>course it raises an interesting question for individuals. Still, it would >>be up to an individual operating as a business to get a taxpayer ID that is >>not his/her social security number. >> >>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 >>************************************************************************************* >> >>|---------+----------------------------> >>| | David Fischer | >>| | <david@drummondgr| >>| | oup.com> | >>| | | >>| | 03/15/2002 03:51 | >>| | PM | >>| | | >>|---------+----------------------------> >> >-------------------------------------------------------------------------------------------------------------------| >> | | >> | To: Christopher Ferris <chris.ferris@sun.com>, CPPA <ebxml-cppa@lists.oasis-open.org> | >> | cc: | >> | Subject: RE: [ebxml-cppa] CPPA version 1.10 | >> | | >> | | >> >-------------------------------------------------------------------------------------------------------------------| >> >>Chris, you are right on the mark. >> >>However, SSN is a bad example. The legislation which instituted these >>numbers >>specifically stated that they NOT be used as a universal identifying number >>-- >>even though they are used that way quite often, even by state governments. >>There are some privacy issues there which it would be best to avoid. >> >>I wonder if it would be better to focus (not exclusively) on something more >>global -- like UCC/GLN -- rather than DUNS. I absolutely agree though that >>there doesn't/shouldn't need to be any *single* central authority for the >>identifiers. I assume that SMEs will end up using eMail addresses as a >>start. >> >>Regards, >> >>David. >> >>-----Original Message----- >>From: Christopher Ferris [mailto:chris.ferris@sun.com] >>Sent: Friday, March 15, 2002 2:24 PM >>To: CPPA >>Subject: Re: [ebxml-cppa] CPPA version 1.10 >> >>Duane, >> >>Please see below. >> >>Chris >> >>Duane Nickull wrote: >> >> >>>Chris: >>> >>>If I thought that would solve the problem, I would have done this. The >>>problem is that a DUNS number is not as easy to get once you are outside >>>the confines of the US. >>> >>That isn't the point. The point shouldn't be to identify a registry >>like DUNS that everyone can, should or must use, it should rather be to >>provide a means that an identifier can be used and mutually understood >>without requiring a centralized process or registry. >> >>A URI provides this capability, that is its purpose. If I had >>my druthers, I'd prefer to see that there were no 'type' attribute >>but that the value be required to be a URI. >> >>More below. >> >> >>>I agree that we cannot close the list. Here is a copy of the email I >>>sent to Dale (Sorry - meant to copy the list): >>> >>>******* MESSAGE ************ >>>Dale: >>> >>>Here are the requirements for this artifact: >>> >>>1. It can globally, uniquely identify a company >>> >>why limit to a company? >> >> >>>2. It is available to any company (worldwide) without unreasonable >>>overhead. >>> >>agreed. >> >> >>>3. Sub-groups within a company MAY need to uniquely identify themselves >>>as a subgroup but within the domain of the company. >>> >>agreed. >> >> >>>On the wish list: >>> >>>4. It can be used to get more definitive information about a company. >>> >>>I think that URI meets all of the requirements and I would be happy for >>>now. Dun and Bradstreets numbers are not easy to acquire globally, >>>therefore are not as desirable for non-USA companies. DUNS is nice >>>though becuase it says that the company has undergone some sort of >>>screening process but that would only be useful if there was a way to >>>verify that the DUNS number was legitimately issued, which there is not >>>(not without manual intervention.). >>> >>>Other items like tax id numbers may be used (need to clarify if they are >>>globally unique if used with a country qualifier) or a unique number >>>registered with a global authority like IANA. >>> >>Or just an adopted URN namespace e.g. urn:www.ssa.gov:ein:123456789 or >>urn:www.ssa.gov:ssn:123456789. The namespace becomes the qualifier for >>the raw ssn or ein number which is managed by the authority that owns >>the URN namespace (in this case, the entity www.ssa.gov which is the >>US Social Security Administration). (note that I'm unclear as to >>whether the SSA assigns EINs or if this is maybe a function of the >>IRS) >> >>The whole point here is that there not need to be a *single* >>central authority for the identifiers, but that those authorities >>that are already in place merely ask for a URN namespace that >>can be applied to their existing identifiers so as to fully >>qualify them so that it can be globally recognized and we can >>end this never-ending debate (which has resurfaced more times >>in the context of ebXML than I care to recall!) >> >> >>>Duane >>> >>>***************************** >>> >>>I have no other ideas off the top of my head. I am glad everyone at >>>least agrees this is a problem. >>> >>>Duane >>> >>>Christopher Ferris wrote: >>> >>> >>>>Duane, >>>> >>>>Sure, we could define an enumeration that included >>>>DUNS, but there are many others out there. If the >>>>enumeration is used, then it is effectively a closed list and only the >>>>owners of the schema can extend to add other namespaces. >>>>This approach seems to me to be quite unnecessarily constraining. >>>> >>>>Why don't you lobby D&B to get (or publicly declare) a >>>>namespace identifier. This has only been an issue for >>>>I don't know how long. Seems to me that the UN could >>>>excersize some of its clout to encourage D&B to help >>>>with this problem. >>>> >>>>Just establishing a closed enumeration is NOT IMO >>>>a viable solution to this issue and I won't support >>>>it if we choose this route. >>>> >>>>Cheers, >>>> >>>>Chris >>>> >>>>Duane Nickull wrote: >>>> >>>> >>>> >>>>>>Tony Weida wrote: >>>>>> >>>>>>CPPA version 1.10 is attached. >>>>>> >>>>>> >>>>>> >>>>>Tony and all: >>>>> >>>>>Until the issue of PartyID attribute "type" is resolved, I wil not >>>>>support this document. I wish to suggest the changes. >>>>> >>>>>Currently you have: >>>>> >>>>><element name="PartyId"> >>>>> <complexType> >>>>> <simpleContent> >>>>> <extension base="tns:non-empty-string"> >>>>> <attribute name="type" type="tns:non-empty-string"/> >>>>> </extension> >>>>> </simpleContent> >>>>> </complexType> >>>>></element> >>>>> >>>>>There has to be somthing sematically meaningful for this to be a party >>>>>identifier. For now, I suggest the following: >>>>> >>>>>Change the attribute content model to an enumerated list of >>>>> >>>>>( DUNS | URL | ... ) >>>>> >>>>>and allow companies to chose one of several types of PartyID's that are >>>>>guaranteed to be unique. If DUNS is guaranteed unique, then it can be >>>>>used but you must specify the semantics of DUNS somewhere. I suggest >>>>>you put this in the specification that governs this schema. Clearly >>>>>state that " a value of "DUNS" indicates the Dun and Bradstreets >>>>>identification number of the company as given by ...". Make the same >>>>>type of statement for any other unique identifiers types you allow int >>>>>he enumerated list. For instance, "URL is instance value of a properly >>>>>formed URL owned by the Trading Partner.." >>>>> >>>>>Otherwise, this is completely useless and will not meet the >>>>>requirements of CPPA. >>>>> >>>>>Please give this some serious thought. We can always expand the >>>>>enumerated list later based on requirements of companies. >>>>> >>>>>Duane Nickull >>>>> >>>>> >>>>> >>---------------------------------------------------------------- >>To subscribe or unsubscribe from this elist use the subscription >>manager: <http://lists.oasis-open.org/ob/adm.pl> >> >>---------------------------------------------------------------- >>To subscribe or unsubscribe from this elist use the subscription >>manager: <http://lists.oasis-open.org/ob/adm.pl> >> >>---------------------------------------------------------------- >>To subscribe or unsubscribe from this elist use the subscription >>manager: <http://lists.oasis-open.org/ob/adm.pl> >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC