Tom Warner's ebXML Requirements Opinion Paper

["Warner, Thomas" <thomas.warner@boeing.com>]

 <<ebXML-ReqGrp-Opinion-Warner.txt>> 
Tom Warner
Manager, Electronic Commerce Initiatives
Integrated Digital Environment Program
Aircraft and Missiles Systems
The Boeing Company
(T) 314-232-0615
(F) 314-777-1704
e-mail: thomas.warner@boeing.com
01/03/00
ebXML Requirements Group
Opinion paper contributed by Tom Warner 

1. Need to address the basic reasons why people want to use XML?

The Business / Customer users want XML because…
- Moves them to 100% paper-less operation.
- Provides one documents format for both browser and computer application 
- Moves them to cheaper web/ Internet solution.
- User oriented solution, does not require a programmer.
- It provides a migration path from EDI to XML EDI to OO-xml/edi 
- Summary:  Its fast, cheap, web based and widely accepted
 
But, Business users don't want…
- To scrap existing EDI investment and operation
- To waste time waiting for the perfect XML solution that would require much
  time, many meetings, much consensus, much re-investment and re-education
- To move to a new, single, complex e-solution which requires too much 
  rethinking of business models too soon.  What if it doesn't end up being the
  "standard".
- Divergent XML DTD developments (similar to EDI divergence)
 
The Technical / Functional users want XML because…
- Now able to build and send self-explanatory document definitions along with 
  the document 
- Now able to expand the scope of document constructs to support object
  technology and UML based document design.
- Now able to achieve truly open, web based e-business solutions with a global
  reach.
 
But, Technical users don’t want…
- To use existing document and element semantics (tags and meaning) from EDI.
- To develop more than one type of XML solution regardless of variations of 
  documents business use or purpose.  (A migration path)
- To provide an interim solution to solve the business objectives expressed in 
  1 above.

2. The "Big Enterprises" are the critical ebXML players. 
- Their business management must be convinced that it will be good for them. 
- They are the same players who have an installed EDI base / investment to 
  protect.  
- The simplest sell to these players will be to provide a migration path from 
  EDI to XML. 

3. Perceptions:
- Any XML/EDI standards should be "complimentary" to any long-term, object-based
  XML standard and should not be seen as "competing".  It’s a matter of 
  perception.
- XML is the de facto, standard, serialized vocabulary of the Internet, EC, EB
  and ERP. Why?  Because it is simple, easy and "ubiquitous" but mostly because 
  it can eliminate the need for different document formats for either human or
  machine readability.  
- It appears that much "XML activity" to date has been a purely technical / 
  functional "recasting" of business interchanges in "interactive form" for an 
  industry specific consortium with minimal cross industry business perspective.
  The "technocrats" are still doing most of the work.
- "The intelligence of XML is carried with the content and not in a software 
  dependent solution."  This is good and bad for standardization, Configuration
  Mgt. and reuse issues.  XML documents and their definitions can be changed on
  the fly.
- XML will not simplify "X12/ EDIFACT alignment".  X12 EDI and EDIFACT are 
  "functionally equivalent (not equal)" and cannot be cross ref. Matrixed 
  without interpolation.   (I know this because I chaired the committee that
  developed the 1st two EDIFACT Messages and I  drafted the X12 to EDIFACT 
  Recasting Tool Kit.  I also worked on the initial X12 / EDIFACT Alignment
  Subcommittee.)  

4. Document Component Use and Reuse Requirements
- XML Documents can be Simple, Complex, Compound, Batch and Interactive. 
  One size of XML solution /standard may not fit all.
- EC/EB Users are Big Enterprises and Small/ Medium Enterprises.  One size of 
  XML may not fit all.  I contend that there should not necessarily be one size
  of ebXML for all sizes of players.
- Global Multi-lingual standards will be a hassle unless there is a "simple 
  language transformation capability" at the "directory level".  We should not
  be building semantically similar solutions in different languages.

5. Lessons learned from Industry and Standards Organizations.
- We cannot expect the same (XML) documents to work the same way for all 
  industries. Case in point: The Telecommunications Industry is spending much
  time in developing telecommunications "sales and service models" and related
  XML documents (modules).  But, these are NOT readily usable by most other
  service industries (such as airline mechanics.) 
- X12 standards are an accumulation of "industry specific business cases
  (scenarios)" which have been normalized/ consolidated into "standard 
  transactions".  This then forced each industry to write its own conventions
  for defining how to extract their "industry transaction subset" out of the
  "standard X12 transaction superset".  To date, there have no ubiquitous, cross
  industry transactions that are usable right out of the box.  Can /should XML
  be expected to solve this problem? 

6. Final Opinion:
- I see no reason why we cannot provide for both X12/XML  and EDIFACT/XML as
  well as a SPEC 2000/XML and a STEP Product Data/XML.  If we move the semantics 
  directly from the existing EDI or Product Data standard to XML without 
  reinventing new tags and taking years to come to a consensus on their meaning,
  then we are better able to migrate the "users" of those standards to the 
  "ultimate ebXML standards".  The more complexity we put into the initial XML
  solutions the longer it takes and the smaller the window of opportunity to 
  gain wide spread use.
- I believe that Industry Groups will continue to be the center of 
  implementation activity for any XML standard.  I see the industry 
  organizations such as AIA, EIA, ATA, AIAG, SWIFT etc. as the best vehicle for
  obtaining acceptance and use within a minimal time period. They are best able
  to match the business solution to the technical capability.  This should be
  exploited rather than be ignored.

END