OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Trading Partner Logical Identification based on EDIFACT or X12qualifiers


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"





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC