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: Re: Trading Partner Logical Identification based on EDIFACT or X12qualifiers


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

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
thru your ISP or merchant or software vendor or similar.

Where does the TPA live?  In the Registry.  Where do the definitions that
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
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

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
use others - they can easily add them.  Remember - we do the technical
then businesses determine the actual information content based on business

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

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

WE HAVE NOT AGREED on who gets to choose the set of "context" values

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

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
context and authority. The specs must provide an extension mechanism to
this type of customization.  For example MIME permits header extensions
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".


[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