OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-requirements message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: ebXML Requirements - Some thoughts


All,

First of all let me say that we had a good kick-off meeting for the ebXML
initiative.  I also realize that we have a very important task of specifying
the requirements for this initiative.

I want to share some general thoughts with you before we get too deep in the
details of the specific requirements.  This will build on my statements at
our first meeting.

The topics discussed below are meant to be a starting point.  Neither the
topics identified nor the discussion is intended to be exhaustive.  In
addition, topic order does not indicate importance in my mind.

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

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.

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.

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.

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.

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.

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.

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

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.

Long haul

Want to know that the process and standards will be there for a long time.

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

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

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.

Hope that this does not sound too long and vague.  This a first attempt at
our overall scope.

Interested in your reaction.


Dr. Donald D. Rudie		100 Locust Avenue	
Vice President			Berkeley Heights, NJ  07922
Global Data Authority		908-665-6088 - Tel#	
rudied@dnb.com		908-665-6325 - Fax#




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC