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

[David RR Webber <Gnosis_@compuserve.com>]

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 ...
<