Re: Trading Partner Logical Identification based on EDIFACT orX12qualifiers

[Gordon van Huizen <gvanhuiz@progress.com>]

Dick wrote:
> 
> 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?

I do agree that there is a separation of the two. I don't agree that we
shouldn't prescribe a preferred mechanism for obtaining the WHAT for a
given party, at least at a LCD level. If we don't do say anything about
the HOW of this bootstrap process I fail to see how we can have
automated discovery and conversations without a priori knowledge of how
a given party exposes their TPA. As I understand it this is a core tenet
of ebXML, and rightly so. The minimal reg/rep access mechanism could and
should be lightweight.

> ebXML is defining an over-the-wire specification within the TR&P specs (headers
> and packaging). This should (hopefully) ensure interoperability.

This will be easier said than done, but I do believe that this should be
the goal.

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

The ability to query an ebXML reg/rep shouldn't require a specific API.
I don't think that's the point. What it DOES require is an agreement on
protocol to use, the manner in which the TPA is formatted and
serialized, and some amount of semantic context. This doesn't strike me
as unreasonable, and is most definitely required for automated discovery
and conversations. I cheerfully submit that this is not possible by
leaving the exposing of TPAs open to such widely varying mechanisms as
fax, braille, grunts, Word documents, scribbled notes taped to carrier
pigeons, or  other amorphous "interfaces".

-gvh-
begin:vcard 
n:Van Huizen;Gordon
tel;work:510-848-1988
x-mozilla-html:TRUE
url:http://www.sonicmq.com
org:Progress Software;SonicMQ Applications
adr:;;14 Oak Park;Bedford;MA;01730;
version:2.1
email;internet:gvh@progress.com
title:Director, Product Management
fn:Gordon Van Huizen
end:vcard