ebXML Requirements - Some thoughts

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

Here is my "one pager" reissued.

This is another e-mail with the same content - 

> All,
> ebXML-Requirements@lists.oasis-open.org
> 
> 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#
>