Rudie ebXML Requirements

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

-----Original Message-----
From: Mike Rawlins [ mailto:rawlins@metronet.com
<mailto:rawlins@metronet.com> ]
Sent: Wednesday, January 05, 2000 12:45 PM
To: List, ebXML Requirements
Subject: Re: Rudie ebXML Requirements


Don, thanks for raising some very good points.  As with many of the
discussions
we've had, I find people offering solutions as well as requirements.  What I
would like to do with this note as well as some of the others is to try to
distill specific requirements from your concerns, and identify issues for
discussion.   When discussing specific requirements we need to be aware of
scope
issues and have some ideas about the impact of satisfying them.  However, it
is
mostly beyond the scope of our project team to recommend specific solutions
to
requirements.  That is what the other project teams will be doing, and we
will
have quite enough to do just dealing with requirements.

"Rudie, Donald" wrote <snipped>:

> >
> > General Comment
> >
> > We heard a lot of comments about this being useful for the SMEs,
however,
> > I think that unless its also useful for the BEs (Big Enterprises) or LEs
> > (Large Enterprises) it won't go very far.  BEs have to deal with other
BEs
> > and SMEs simultaneously.  Since the majority of BEs are already heavy
EDI
> > (X12 or EDIFACT) users, they have to be able to operate in that mode
while
> > they are trying to branch out and reach SMEs that may come up fresh
using
> > XML.

I think most of this is covered by what I called scalable implementations -
it
should work for SMEs as well as large enterprises.  The other might be
covered
by maximizing interoperability with current EDI standards.  Don, do these
cover
what you are trying to express here?

DDR Comment

Mike, No.

The basic requirement here is that when the BE/LE expands their trading
partner base for the traditional EDI partners to partners using ebXML
standards (probably SMEs) they want some assurance that the information
content and the manner of expression is the same.  That is, they will
receive (in their application system) the same data element definition, code
values, semantics from the SME that they receive from the BE/LE.

The processing logic in the application system should not depend on the
source of the data -- EDI or XML.

For example, the purchase order for a widget from a BE/LE using EDI should
contain the same information content, etc. as a purchase order for the exact
same wedget from an SME created according to the ebXML rules.

This flows on to data element definitions, code values, versioning, legal
requirements, etc.

It seems to me that unless we state this as an ebXML requirement the BE/LE
who understands this won't use or endorse ebXML.

>
> >
> > I also think that we must try to avoid one of the problems that occurred
> > in the early days of EDI.  -- trading partner pairs and then industry
> > groups can come up with their own set of standards for quick starts.  It
> > didn't take long to discover that no business, or industry group is an
> > island, unto themselves.  Incompatible trading partners started to bump
> > into one another.

I'm afraid we are already into that.  A deliverable of a single XML business
standard could prevent further fragmentation.   A single standard as a
deliverable would satisfy the goal of maximizing interoperability between
XML
enabled business applications.

DDR Comment

I agree.  This will create the same sort of problems that occurred in the
pre X12 EDI days of the 70's
> >
> > We need to figure out a way to allow new things to be added quickly, but
> > at the same time guard against the situation where we have two different
> > ways of specifying the exact same thing.

This sounds like a standards process requirement that is responsive but also
has
controls to prevent creation of equivalent components.

DDR Comment

I agree
> >
> > ebXML Semantics
> >
> > The ebXML semantics should at a minimum cover the semantics contained in
> > X12 and EDIFACT.  This is not to say that every X12 Transaction Set nor
> > EDIFACT message be specified within ebXML -- only that one could if
> > desired express the TS or message in ebXML.

I see two distinct requirements:  One that ebXML semantics should
incorporate
all that is currently defined in X12 and EDIFACT.  This is a very tall order
that greatly increases the scope of the ebXML effort.  How long has it taken
to
come up with current X12 and EDIFACT semantics?  The other again deals with
maximizing interoperability with current EDI standards.

DDR Comment

I am not saying that we should start over, only that we should take
advantage of the rich set of X12, EDIFACT semantics and state as a
requirement that they be included in the ebXML semantics probably as a
subset.  Hopefully we can find a way to expressing them by an "automated
process".

> >
> > We may, however, have to be able to distinguish between X12 and EDIFACT
> > semantics at the instance level.

> >
> > We may very well want to go beyond the semantic requirement of X12 and
> > EDIFACT, however for our short term delivery we may want to use those as
> > our baseline.

If I understand correctly, you think we should maximize interoperability
with
both X12 and EDIFACT.  A solution to this might be supporting both, but that
is
in conflict with delivering a single standard.   Are you advocating that we
develop a single set of semantics in the long term, and focus in the short
term
on ways to use existing EDI standards for semantics at the expense of
maximizing
interoperability between ebXML implementations?

DDR Comment

Back to my first point.  We should want to avoid (if possible) the situation
where the "specifications/requirements" for an ebXML purchase order destined
for an X12 oriented application system is different from the same ebXML
purchase order for an EDIFACT oriented application system.

I realize that this is a tall order because of the differences between X12
and EDIFACT, however, there are alignment activities taking place in the
X12, EDIFACT world and our requirement for a single standard could build on
that.

Regarding your last statement do not see the focus on existing EDI standards
as an expense of maximizing .. rather I see it as a way to jump start the
process since we don't have to create off of the semantics from scratch.
> >
> > ebXML tag names
> >
> > It think we should try to use one set of tags to cover both X12 and
> > EDIFACT semantics rather that one for X12 orientation and one for
EDIFACT.
> > We will need to distinguish content (e.g. code values), however, this
> > should be specified higher up in the exchange or referenced somehow.

This sounds more to me a solution than a requirement.

DDR Comment

I don't think so.  Making this a requirement will increase interoperability.

> > Internal/External Codes
> >
> > ebXML must be able to handle the internal and external codes used by
both
> > X12 and EDIFACT.  The X12 dictionaries and the EDIFACT Directories
should
> > be the source for internal codes and identify the source of external
code
> > lists.  Again we may want to go beyond X12, EDIFACT; however, we still
> > have the potential compatibility issue.

This is another aspect of interoperability with current EDI implementations
-
use common code lists.  The other would be common message structure.  Again,
we
raise the issue of maximizing interoperability with current EDI vs. maximum
interoperability for ebXML.  Note:  This also assumes that ebXML is even
going
to use code lists.  One could certainly come up with a design where
everything
was done with meaningful XML element names and no codes (use as attribute
values).  I think we might say that "if codes are used, then...", without
specifying that codes should be used.

>DDR Comment

I agree, so long as it will work for the BE/LE -- SMEs talked about above.
> >
> > We want to make it easy to add/modify new codes/code sources, but we
need
> > rules so that it doesn't get out of hand.  The EWG model works pretty
> > well.

Again, a process requirement dealing with rapid approval of changes.

>DDR Comment

I agree

> >
> > Code Use
> >
> > We need to make certain that the codes and code lists usage in ebXML is
> > the same as EDIFACT and X12.  That is, we don't want a situation where a
> > business application process must reconcile the differences between e.g.
> > an EDIFACT Purchase Order feed and an ebXML Purchase Order feed.
> >
> > This does not mean the ebXML specifications should not go beyond X12 or
> > EDIFACT

Again, this sounds to me like the traditional EDI and ebXML interoperability
requirement.

>DDR Comment

I agree
> >
> > Open Process
> >
> > You would want to have an open process in place whereby they can go to
> > request addition/deletions/and Modifications to the semantic messages or
> > code values.  Suggest that it be under the UN.  Also we do not want the
> > process controlled by some interested group who could arbitrarily shut
> > them off.
> >
> > Thus the UN process.

We can specify that the standards maintenance process requirement be open.
I
don't think it is appropriate for us to specify a specific process, such as
the
UN process.

>DDR Comment

No, but we could specify the requirements such that this is a good solution.
> >
> > Long haul
> >
> > Want to know that the process and standards will be there for a long
time.

An organizational requirement for a body that is responsible for long term
maintenance of the standard.

>DDR Comment

YES
> >
> > Concerned that some group starts a process and since they really control
> > it decide for business reasons to shut it down.

Again, a process requirement for an open, consensus driven process.

DDR Comment

YES

> >
> > Keeping the process under the UN umbrella is seen as the best way to
> > guarantee the long haul. 50-100 years.

Again, I suggest we focus on the requirement in this project team and not
the
solution.

>

> >
> > Archives - A look into the future
> >
> > There is a need to be able to reconstruct the exact information content
of
> > a message received 20-30 years ago.  It may be required for example in a
> > legal court setting.
> >
> > Need to have standards versioned and historically understandable.

This is very good.  It could perhaps be restated in terms of archivability
or
retrievability - the ability to reconstruct and interpret the semantics of
an
ebXML encoded document in perpetuity (or set a time limit - 30 years from
creation?).  Versioning is a mechanism to help achieve that, so might be a
solution rather than a requirement.  However, we could perhaps specify
version
identification and control as a detailed requirement.

--DDR Comment

Bob Miller has also added some points here.


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