Re: Trading Partner Logical Identification based on EDIFACT or X12qualifiers

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

Arrrrggghhh!

Dick this is NOT what I had in mind.  Its good that we're having this
dialogue.

Your TPA determines who/what/where - even if, as Rachel pointed out,
the TPA you are using is actually a proxy TPA (becuase you are just a
consumer)
thru your ISP or merchant or software vendor or similar.

Where does the TPA live?  In the Registry.  Where do the definitions that
the 
TPA  reference live? In the Repository.

Here's the sequence.

Transport layer receives Header. Inspects - sees reference to Context it
does not
already know.  Queries Repository for definition of Context (the bit your
are probably
missing here is that the Schema or DTD associated with the transport header
contains
the XML IDREF lookup into the repository for this) - so the 'flavour' of
ebXML header
 you are using already points to these cross-references.

Now armed with this info' the Repository tells you this should be a
X12/DUNS combo.
You can then use this to reference TPA from the Registry and validate the
header.

So - in answer to your question - NO - we should not be defining what codes
lists we
use - only a SAMPLE of using code lists, and how if someone wants to define
or
use others - they can easily add them.  Remember - we do the technical
spec's,
then businesses determine the actual information content based on business
need.

So the action item is -

1)  Pester Tech Arch and RegRep to define interface spec's - 
        these are somewhat there in doc's - but need better use cases et
al.
2)  Pester RegRep to give spec's on API for 1) - 
        we're working on those hot and heavy for the POC - more soon, 
       but not too soon  - I've lots of project work over next couple of
weeks....

Thanks, DW.
========================================================================

Message text written by INTERNET:dick@8760.com
>
ACTION ITEM 1 - identify a core set of values that can be used in the
"context"
attribute.

WE HAVE NOT AGREED on who gets to choose the set of "context" values
(regrep,
TRP, CC).

ACTION ITEM 2 - decide which group should define the list of values for
"context".

I propose we address action item 2 first and 1 will soon follow.

One requirement:

Any two trading partners should be permitted to use non-standard  values
for
context and authority. The specs must provide an extension mechanism to
allow
this type of customization.  For example MIME permits header extensions
through
the X-hhhhhhh option, X12 has the "ZZ" qualifier, etc. Consider a possible
example, using Amazon:

<PartyId context="X-Amazon" authority="userid">RJB9876</PartyId>


This, I believe, would address David B's concern over having parties
pre-register with recognized "Name space management organizations".

<