Subject: Re: PartyId and Context
Scott Hinkelman remains "skeptical that people will stop concocting their own ad-hoc name schemes." He "[believes] industries/groups will continue to do this for reasons of lingo ,etc, regardless of how logical it may be to have consistency," so he favors "allowing them to do it, and minimize ebXML buy-in." Scott loves URIs: "They are beautiful. But I'm not yet convinced to mandate everyone to use it." Industries and groups have, and will continue, to concoct their own naming schemes since those schemes are devised to suit their own purposes, of which ebXML is not one. For example, Dun & Bradstreet assigns company IDs for their business reports. The National Motor Freight Traffic Association assigns Standard Carrier Alpha Codes (SCAC) to carriers used to report tariffs and other regulatory stuff. The Uniform Code Council assigns UCS Comm IDs to all their members in the grocery and retail industry. The Federal Government assigns FEINs to each employer. S.W.I.F.T. assigns the ISO 9362 Bank Identifier Code (BIC), a universal identifier for financial institutions throughout the world. Each bank in the U.S. has a Transit Routing Number assigned by the American Bankers Association (ABA); it appears on your own checks. There are any number of different codes to identify secondary and post-secondary educational institutions. Most of these IDs predate ebXML and EDI, and will be continue to be used as the primary means of identifying organizations. Nobody is going to pay attention to any demand to get yet another ID just in order to conduct e-business using ebXML. They will want to use existing identifiers. We must accommodate that desire by making their usage transparent. It's not logical to have consistency for IDs, because it's not at all necessary for ebXML's purposes. As long as we can identify a party by any of these types of existing schemes, we will have succeeded in solving the PartyID and Context conundrum. Charlie Fineman guesses "we could do an respectable job of identifying the existing naming schemes and not have to evolve that list very much in the future," and "this does not equate to ebXML [becoming] a registry for the names themselves but it would require that ebXML be a 'registry' (largely static) of the TYPES of names that can appear in party IDs." There's no need for ebXML to become a registry for these schemes (e.g., DUNS, SCAC, EAN), because there is already EDIRA and ISO 6523. And if ISO 6523 doesn't list your favorite scheme, you might be able to find it listed in the code lists for EDIFACT ISO 9735 D.E. 0007 routing Identification Code or ANSI ASC X12's I05. These three places are the only "catalogs" of schemes that I know of that are readily available and maintained on a regular basis. Maintenance is the key: if a business identifier scheme is not found in one of these three places, there are undoubtedly processes by which the BSI will add a new ICD to ISO 6523 for which they are the registration authority, the JSWG for ISO 9735's list of schemes, and ANSI ASC X12 for X12's code list. Taken together, these three places have hundreds of naming authorities listed, though some are duplicated in all three (e.g., DUNS). That's not a terribly big number - Charlie is right: we could build our own list based on what we find in ISO 6523, ISO 9735 and ANSI ASC X12. But why bother even with that much work? Just provide some way of saying in <PartyID> that a particular party is identified by organization ID "RDWY" that was assigned by the registration authority whose ID is "02" defined as a code value in Element I05 maintained by ANSI ASC X12. Or, alternatively, give us some way of saying that a particular party is identified by organization ID "006998397" that was assigned by the registration authority whose ID is "0060" defined as an ICD In ISO 6523. Guess what? These two different organization IDs point to the same company: Roadway Express in Akron, Ohio! "RDWY" and "006998397" are Roadway's SCAC and DUNS, respectively. No mess, no fuss, and we certainly don't have to bother the NMFTA (the RA for the SCAC) or Dun & Bradstreet (the RA for the DUNS) asking them to register some type of URI with the IANA. And Roadway doesn't have to screw around with obtaining an "ebXML" identifier: they already have plenty of unique IDs, why do they need another? VANs already know how to get data to Roadway Express using either solely the SCAC or the DUNS identifier. I could go on and give more examples: organization ID "9254110060" assigned by the RA identified by code "8" in ISO 9735 uniquely points to the Kroger Co. in Cincinnati, Ohio; "9254110060" happens to be Kroger's UCC Communications ID, and "8" in ISO 9735 says it was assigned by the Uniform Code Council. Want more? Organization ID "003658" assigned by the RA identified by code "22" (Federal Interagency Commission on Education) in ANSI ASC X12's Interchange ID Qualifier uniquely points to the University of Texas at Austin. Building a namespace containing definitions for hundreds of RA identifiers, as Charlie might want, brings the concomitant headaches of maintenance, especially keeping it in sync with the concurrent changes to ISO 6523, ISO 9735 and ANSI ASC X12. I presume the BizTalk Framework 2.0 requires this for the <address> BizTag. But if we use the indirect approach, which I think Scott Hinkelman was alluding to, we only have to maintain a small list of three registry identifiers, denoting ISO 6523, ISO 9735, and ANSI ASC X12. I'll volunteer to build the namespace element types: how about "ISO_6523", "ISO_9735" and "ANSI"? Then we're back to what I originally suggested back in August, using a two-tiered logical addressing structure, in "Trading Partner Logical Identification based on EDIFACT or X12qualifiers," at http://lists.ebxml.org/archives/ebxml-transport/200008/msg00073.html. David Burdett may want to turn this into a URN, to which I have no objection, e.g.: urn:ebxml.org:partyid:context:ISO_9735:authority:8:value:9254110060. That aside, David Burdett told Henry Lowe that "...we have been through this loop once before in TRP. What is now happening is that other groups such as RegRep and TP are getting involved which is actually very good. I think that we should be able to come to resolution in a way which meets everyones needs soon. This will be good as there will then consistency across groups." Well, not only do RegRep and TP have to be dragged into <PartyID> definitions, but so does Core Components: see my comments on the Party Identity aggregate at http://lists.ebxml.org/archives/ebxml-core/200012/msg00019.html. William J. Kammerer FORESIGHT Corp. 4950 Blazer Memorial Pkwy. Dublin, OH USA 43017-3305 +1 614 791-1600 Visit FORESIGHT Corp. at http://www.foresightcorp.com/ "Commerce for a New World"
Powered by eList eXpress LLC