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 X1 2qualifiers


Message text written by David Burdett
>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
<<<<<<<<<<<<<<

These are only issues in our minds (mostly!).

The tpaML thing is where the rubber hits the road.  If I can have a tpaML
profile where most of it is 'none / default / any / unknown' then its easy
for a SME to join up.  Actually their ISP should provide defaults
automatically
of any domain stuff into a tpaML profile - so they won;t even see that.

I do NOT think there will be a power issue - because frankly ANY repository
can play - so that means rapidly you have competition on providing access.

You have to have some accountablity and traceablity to avoid fraud (there
will
be fraud - nothing is 100% - but you should strive for 90%+)

Domain names just do not give you any sort of granularity into information.
The use of namespace as a qualifier (as in GUIDE) is OK - but then you
need specific labels (IDREF's) within that to locate what you need.

Whether the namespace points at some complex registry/repository, or
if the Reg/Rep is in fact a simple XML file stored in a sub-directory and
the Web server can do IDREF style query against the content (i.e. extremely
simple) that is really an issue of implementation.

Then there's the impending Schema support issue.  GUIDE is an approach
to letting you do both - and uses reference mechanisms that work well
in both worlds.  Simple URN is going to have a tough time with Schema
extensions, but that's a technical aside, returning to the business
focus....

I'd like to see the Transport layer 'repository enabled' so that these
references can be resolved simply and easily, while at the same time
providing robust and honest information retrieval.   This is not difficult
to
do with simple http based query/response, and definately adds 
significant value to an interchange header in terms of interoperable and
secure exchanges.

We've never said there is a restriction on content - just that content 
needs to be authenticated - the difference between a Yahoo search 
engine and an Ask Jeeves - its all in that business classification layer
in GUIDE!  

That's why I noted that some of this is to be determined as we work toward
Tokyo.

Thanks, DW.


[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