Re: Tom Warner's ebXML Requirements Opinion Paper

[Mike Rawlins <rawlins@metronet.com>]

My comments on Warner's paper, flagged MCR.

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

MCR - I think these all map into my requirement to minimize costs.

But, Business users don't want…
- To scrap existing EDI investment and operation

MCR - Does this mean you favor a high degree of interoperability with current
EDI, i.e., a mechanical translation between formats?  Or, do you care more
about minimizing impact on existing integration with business applications?

- To waste time waiting for the perfect XML solution that would require much
  time, many meetings, much consensus, much re-investment and re-education

MCR - A requirement to have deliverables in a short time frame.  We have
discussed having something basic in 6 months and the whole solution in 18.

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

MCR - This sounds like a new requirement that implementing ebXML should not
require changes to existing business models or practices.  Or, put positively,
ebXML should support current business models and practices (as well as new ones
developed through UML modeling).

- Divergent XML DTD developments (similar to EDI divergence)

MCR - Sounds again like a deliverable for a single standard.

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.

MCR - The way this is phrased, you are stating the reasons why technical and
functional users like XML.  I'm not quite sure how to restate these as
requirements.

But, Technical users don’t want…
- To use existing document and element semantics (tags and meaning) from EDI.

MCR - Are you saying that there *isn't* a requirement for maximum
interoperability with current EDI?

- To develop more than one type of XML solution regardless of variations of
  documents business use or purpose.  (A migration path)

MCR - A requirement for a single approach

- To provide an interim solution to solve the business objectives expressed in
  1 above.

MCR - A requirement for a single approach.  OK if delivered in phases, as
opposed to a short term vs. long term?

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.

MCR - I read here a requirement to provide a clear migration path from
traditional EDI to XML based EDI.

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

MCR - I agree that all of these are common perceptions.  Do you want to distill
some requirements from them?

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.

MCR - I think these map to my requirements for scalability and flexibility.
Also, you express a requirement to support both batch and interactive modes.

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

MCR - Again, scalability

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

MCR - A requirement for a single standard with multilingual support
(internationalization).

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

MCR - A recognition that we will have vertical as well as horizontal documents.

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

MCR - It seems to me that you raise an issue for discussion here.  "Should
ebXML be expected to provide universally applicable cross industry document
definitions?"  My opinion is that this is a business model and practice issue,
not one for ebXML.  However, I'll put it on the issues list.

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.

MCR - This seems to me to be in conflict with your statements above about not
wanting interim solutions, and that technical users don't want to use existing
EDI semantics, etc.  Where to you stand on this as a requirement?

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

MCR - Agreed.  As a strategy we should be working with appropriate industry
groups.  Taking a stab at restating this as a requirement, maybe we could say:
"Gain consensus and support by enlisting the involvement of appropriate
industry groups"?

END

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