RE: Trading Partner Logical Identification based on EDIFACT or X1 2qualifiers

[David Burdett <david.burdett@commerceone.com>]

David

You say ... "There needs to be a strong BOND between the RegRep and the
Transport layer." ...

I don't think RegRep can, on its own, solve the problem. RegRep can provide
a specification for HOW things are stored and retrieved from a repository.
The thornier question is WHO decides what goes in the repository. Because if
we require that companies/organizations/individuals are registered before
they can use ebXML then:
a) we are creating a barrier for SMEs - which is against our objectives
b) whoever controls access has a lot of power ... which they probably
shouldn't have.

To my mind, the relative open access provided by the existing Domain Name
System (via URN/URIs), is something we should leverage whilst still allowing
existing naming/numbering schemes from ISO/X12/EDIFACT to co-exist.

David

-----Original Message-----
From: David RR Webber [mailto:Gnosis_@compuserve.com]
Sent: Monday, August 14, 2000 12:18 PM
To: David Burdett
Cc: 'William J. Kammerer'; ebXML Transport (E-mail)
Subject: RE: Trading Partner Logical Identification based on EDIFACT or
X1 2 qualifiers


Ah ha!!!

Gotcha.  This is EXACTLY the issue I was raising in San Jose and
before.

There needs to be a strong BOND between the RegRep and the
Transport layer.  The GUIDE proposal is aimed at establishing that bond.

Notice the trnasport POC did NOT show the diagram of the Tech Arch
and how Transport links to RegRep.

Every entity in the Transport header of this ilk should find its definition
in the Repository - its that simple - that's in the Requirements, and also
in the Tech Arch.

This is a complete extensible system, and thru this you never have to ask
your question again since all the lookup tables and references are 
defined, if the interchange is ebXML compliant, by the appropriate RegRep
reference.

Now - how do trading partners pick a codelist?  Well that is down to them
to
decide best practice for their industry, and then to put that into the
RegRep
they are using to define the interchanges.

We will be making more of this clear as we start work into the POC for
Tokyo and drill down on the RegRep specifications accordingly.

Thanks, DW.
================================================================
Message text written by David Burdett
>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 ...
<