Re: Trading Partner Logical Identification based on EDIFACT orX12qualifiers

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

Dick you contradict yourself here!  On the one hand you have machine
requirements to interchange headers, then say its too much work to
do the repository as well.  Frankly I'm not impressed.   My two cents worth
is if you can handle all that MIME and SMTP stuff - you can surely do a
simple http query/response!  AND going forward we want to move to a
clean second generation XML/http layer anyway - MIME is a current
generation solution.

PLUS - and this is a big PLUS - what the heck is this?  I'm sorry but the
whole point of ebXML is to NOT sink into the EDI mire again.  EDI took
so blasted long to set up precisely because there was no MANDATED 
machine API interrogation.   Word Docs, FAX's, that's not acceptable,
its just trying to justify consultant time tinkering with stuff they should
never
have to touch. 

Plug-N-Play for EDI - is that too radical?

I say we make the Repository functionality mandatory, and show 
lightweight alternatives for when people are using it in-house to go
between two servers on their own systems (that has to be the 
least case use model).  A 'Repository' can then be as simple as an
ebXML-TRP.ini file in a sub-directory that contains the interchange
formats.

DW.

Message text written by INTERNET:dick@8760.com
>
Let's not confuse WHAT information has to be provided to make ebXML work
with
HOW the information is provided. I think we all agree that ebXML parties
must
agree on WHAT information is needed but HOW this information is obtained
and
stored will depend on many factors. Do we agree?

>
> If that's the case, and we're not careful to establish over-the-wire
> interoperability between ebXML messaging service implementations, remind
> me again why we're bothering to do ebXML?
>

ebXML is defining an over-the-wire specification within the TR&P specs
(headers
and packaging). This should (hopefully) ensure interoperability. ebXML is
also
defining WHAT information trading partners need in order to conduct
E-Commerce
using ebXML. The point of this discussion is whether or not a ebXML host
MUST
provide a regrep API  to ensure interoperability. I contend that a
repository
API IS NOT a requirement for interoperability because the information
needed to
exchange ebXML messages can be provided through several means (e-mail, word
docs, fax, et al). A regrep API might make the process more efficient in
some
cases, but it shouldn't be  a mandatory requirement.

> Or are you suggesting that Amazon doesn't need to be ebXML-compliant,
> but ebXML providers need to interoperate with whatever they have? That
> seems way outside the scope of ebXML, and into the land of vendor
> support for multiple eBusiness protocols/frameworks.
>

My main point is this;  some parts of ebXML are absolutely mandatory to
ensure
interoperability between trading partners, standard headers and packaging,
are
two classic examples. I DON'T believe a "repository interface (API)" is
needed
to ensure interoperability. There are many ways to convey the information
about
HOW two parties engage in ebXML compliant E-Commerce without making this
information available via a programmatic interface. Would a standard
programmatic interface be useful - of course - in some cases, but not all.
The
Amazon example is one case where a programmatic interface to an ebXML
repository
is unnecessary.

Dick
<