FW: Trading Partner Logical Identification based on EDIFACT or X12qualifiers

[richard drummond <rvd2@worldnet.att.net>]

we need cc/bp to give us some definitions here... for our addresses... best
regards, rik

-----Original Message-----
From: David Burdett [mailto:david.burdett@commerceone.com]
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:me@xyz.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:wkammerer@foresightcorp.com]
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"