Re: Rudie ebXML Requirements

[Mike Rawlins <rawlins@metronet.com>]

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?

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

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

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

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

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

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

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

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

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

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

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


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

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