[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: FW: Trading Partner Logical Identification based on EDIFACT or X12qualifiers
we need cc/bp to give us some definitions here... for our addresses... best regards, rik -----Original Message----- From: David Burdett [mailto:firstname.lastname@example.org] Sent: Monday, August 14, 2000 1:30 PM To: 'William J. Kammerer' Cc: ebXML Transport (E-mail) Subject: RE: Trading Partner Logical Identification based on EDIFACT or X1 2qualifiers William Firstly I like your description of the current spec definition of party id as "loosey-goosey" ;) - in a sense your're right the current spec is not precise enough. It is clearly important that the identifiers of the "from" and "to" are linked to a registry so that their meaning is unambiguous. However I'm not sure that what you suggest will be sufficient. Specifically: 1. How do we develop a prescriptive list of what is allowed inside Context? Do we specify the list or is there some other authority or standard that we use. If we specify the list, what mechanism/process/procedure do we follow to allow Context to be extended? Can we do this without another registration authority? 2. I also envisage that there may be some naming/numbering schemes that do not follow existing ISO/ASCX12/EDIFACT numbering scheme - how can we support those? I also think that URIs (rather than just URNs) could be useful in resolving this problem since it would allow URLs to be used as an alternative Unique identifier, for example ... <PartyId>url:mailto:email@example.com</PartyId> ... we could also devise a URN structure to support existing ISO/ASCX12/EDIFACT codes along the lines of ... <PartyId>urn:ebxml.org:partyid:context:ISO9735:authority:1:value:003897733</ PartyId> ... as well as allow the use of the URN naming mechanism that could be of the form ... <PartyId>urn:ebxml.org:partyid:context:example.com:value:078391AB32</PartyId > ... which would allow example.com to define it's own codes in a unique way, and also ... <PartyId>urn:tel:+15731234567</PartyId> ... some of our customers use telephone numbers to identify the "To" party for EDI purposes. Thoughts? David -----Original Message----- From: William J. Kammerer [mailto:firstname.lastname@example.org] Sent: Monday, August 14, 2000 6:51 AM To: Dick Brooks Cc: ebXML Transport (E-mail) Subject: Trading Partner Logical Identification based on EDIFACT or X12 qualifiers Dear Dick: Line 454 in the ebXML Transport, Routing & Packaging Messaging Service Specification Working Draft 10-August-2000 (ebXML Messaging Service Specification v0-1.doc) at http://lists.ebxml.org/archives/ebxml-transport/200008/doc00003.doc describes the From and To elements in section 3.3.1. The From and To elements identify parties using "a logical identifier, which MAY take the form of a URN." The examples of the From and To elements of the ebXMLMessageHeader show usage of the DUNS number where the context attribute is set to "DUNS" and the text value is presumably a DUNS number of the sender or recipient. Unfortunately, the examples show 5 digit numbers whereas real DUNS numbers are 9 digits: <From> <PartyId context="DUNS">12345</PartyId> </From> <To> <PartyId context="DUNS">54321</PartyId> </To> I suggest you just pick some real 9 digit numbers to use in the examples. While we're on the subject of logical identifiers, I have discussed various mechanisms for specifying logical IDs - namely those qualified by the EDIFACT ISO 9735 D.E. 0007 routing Identification Code and X12's I05. See "Re: Message Header Info" of 14 Feb 2000 at http://lists.ebxml.org/archives/ebxml-transport/200002/msg00066.html, and "Re: Definition of Business Processes" of 11 Feb 2000 at http://lists.ebxml.org/archives/ebxml-transport/200002/msg00050.html. We might need two attributes in the <PartyId> element, one to specify the promulgator of the code list (e.g., ISO 9735 EDIFACT syntax, ANSI ASC X12, or ISO 6523 Structures for the identification of organizations and organization parts), and the second to give the specific naming authority (e.g., DUNS, EAN, etc.). The codes should just reuse those available from EDIFACT, X12 or ISO 6523, rather than inventing new ones like "DUNS". For example, <To> <PartyId context="ISO 9735" authority="1">003897733</PartyId> </To> would indicate that the payload is to be sent to Compaq, whose DUNS No. is 003897733. ISO 9735 D.E. 0007 code value 1 has a definition of "DUNS -Dun & Bradstreet." Alternatively, the same "semantic meaning" (DUNS) could be specified with the attributes context="ASX X12" and authority="01". Both the EDIFACT and the X12 lists would have to be supported since the two lists do not overlap (e.g, X12 has qualifiers for a logical IDs consisting of a U.S. Federal Employer Identification Number). When they do overlap, the code values are usually different (as above, for DUNS). If the "context" attribute were "ISO 6523", then the "authority" attribute would be one of the International Code Designators (ICD) issued by an International Registration Authority (RA) at http://www.sdct.itl.nist.gov/~ftp/www/x3l8/sc32wg2/ICD_list.htm. I described in Re: Message Header Info how to find the code values for D.E. 0007, Identification code qualifier at the JSWG's web page. But unless you received my EDISIM Standards Reference CD business card, you'll have a hard time finding the code values for X12's I05 Interchange ID Qualifier. If EDISIM is not handy, then you can look up the code values for D.E. I05 by extracting the igML representation for ASC X12 004010 at http://www.foresightcorp.com/igmldev/, and looking for the <DictDataElement> for ID="I05" within the <ElementDictionary>. The DUNS is certainly the most common logical Identifier used in the U.S., whereas the EAN location code is often used in Europe. But other common IDs are used (such as the UCC EDI Communications ID) and can't be ignored or left up to a loosey-goosey definition in section 3.3.1. There's no need for ebXML TR&P to replicate the code lists already defined by X12 and EDIFACT if the "context" attribute simply refers to those standards as I've described, and the new "authority" attribute is simply an EDIFACT, X12 or ISO 6523 defined authority's code value or ICD. 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