Comment on Issue 1

["Rudie, Donald" <RudieD@dnb.com>]

I believe that our maximization (I guess I should spell it with an "s"
rather than a "z" to reflect that I am operating in a United Nations rather
than a USA world) should permit the following:

Company A (LE) exchanges and processes EDIFACT messages with several other
LEs and BEs.  They have expressed their business functions (business
semantics?) within the EDIFACT messages.  They use a common set of codes
from the EDIFACT directory and have established an agreed to set of outside
codes.  There legal agreements are binding to directory releases.  They know
how to reconstruct prior messages, etc.

They have worked out all of the details to go from the output of their
translator to their application system.  Now an SME comes along and wants to
perform the same business process with Company A, however, they want to use
ebXML rather than EDIFACT.

Company A wants to maximize the interoperability of the ebXML messages with
their EDIFACT messages.  One must be able to express the business semantics
using ebXML to get the exact same meaning contained in the EDIFACT message;
the same code values, the same codes, the same legal protection, the same
archiving, etc.

If this is considered to be maximizing EDI interoperability, than its my
higher priority.  If this is what we mean by maximizing ebXML
interoperability then I'm for it.

Without this, Company A will have to develop the capability to exchange
ebXML messages with the SMEs which probably represent a large number of
entities for a small piece of their total business.

Part of the development will include a reconciliation of the differences
between the EDIFACT messages and the ebXML ones.  A non trivial task that
will grow over time.  I also consider this to be minimum scope not maximum.

DON  

-----Original Message-----
From: Mike Rawlins [mailto:rawlins@metronet.com]
Sent: Tuesday, January 11, 2000 1:59 PM
To: List, ebXML Requirements
Subject: Comment on Issue 1


I believe that maximizing interoperability between ebXML applications
(by having a single set of cross industry semantics and presentation)
*and* having an initial set of deliverables are both primary
requirements.  Interoperability with existing EDI is secondary.

It is interesting that Tom considers himself a business person
(non-technical), sees the business side as being difficult, and prefers
a technical solution of mapping the different standards to each other.
I am primarily technical, and while I acknowledge that solving the
business problem of agreeing on common semantics and presentation is
difficult, I think it is preferable to the technical solution.

My opinion is based on several considerations:

1)   Regardless of how much easier people claim it will be with XML
oriented tools than it is with traditional EDI and related tools, it is
still not going to be a piece of cake.  We will be forcing a multitude
of one-on-one conversions, many of which may use document structures and
attribute sets that do not map easily to each other.  We may also be
forcing a whole population of programmers and techies to learn XSL and
related tools.  Even if easier to use end user transformation
programming tools become available, we still will be forcing people to
do the equivalent of EDI mapping.  This conflicts with the requirement
to minimize costs of programming for developers and end user
implementors.

2)   If we implement a short term solution based on interoperability
with traditional EDI, it will persist into the long term.

3)   Market Perception and Acceptance - The market would like to
perceive ebXML as a single, global XML/EDI standard.  When people
realize that we are not going to provide a set of standard documents,
that will damage acceptance and credibility.  If people further learn
that we aren't even going to provide a standard set of element names and
attributes, and only supply specifications for some or all of the
infrastructure, they will further dismiss the effort.

I think that the only way to achieve the two primary requirements is to
adopt an existing set of semantics/presentation, rather than develop one
within ebXML.  It will likely not be perfect and may need some work, but
that will be preferable to not meeting the requirements.

--
Michael C. Rawlins, Rawlins EDI Consulting
http://www.metronet.com/~rawlins/