Rawlins ebXML Requirements

[Mike Rawlins <rawlins@metronet.com>]

Folks,

Here is my contribution for requirements.  As I said at the meeting, I
don't represent any particular set of users and offer these based only
on my own experience in dealing with EDI clients.

Regards,

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

Rawlins ebXML Requirements

This list generally follows the proposed outline.  Where I see a significant issue or decision to be made, I highlight it with "ISSUE:".

I see three major functional requirements and one non-functional requirement expressed in the Terms of Reference and discussions which clarified the ToR.    The functional requirements are:

* Exchange business documents between applications (using XML) - This is the application to application area in the ToR.
* Display business documents (represented in XML) using the appropriate U.N. Layout Key when such a layout key exists - This covers application to human.
* Enable data entry of business documents (represented in XML) using the appropriate U.N. Layout Key when such a layout key exists - This covers human to application.

The major non-functional requirement stated in the ToR is Interoperability.

In addition to interoperability, I believe there are two other major non-functional requirements.  The first is the reason we are even considering XML over traditional EDI.   That requirement is minimizing cost of application-to-application exchanges.  The second is internationalization, i.e., the ebXML approach should meet the needs of all nationalities that use it.

All other requirements, including any dealing with repositories, modeling, security, etc., are secondary to these.

The functional requirements require little elaboration.  However, we must decompose the non-functional requirements and further clarify their meaning.

Note that in most cases, as we maximize interoperability we may also minimize cost.  Therefore, these requirements are synergistic.

Maximize Interoperability
--------------------------------

To maximize interoperability, the following requirements must be met.  Some aspects will assuredly conflict with other non-functional requirements.    Where a requirement is not met, software can usually be developed to achieve a bridge.  However, such bridges may increase costs of development, implementation, or both.

* Common Semantics - Meaning, as distinct from words or presentation.  ISSUE:  Shall we adopt an existing set of EDI semantics (UN/EDIFACT or X12), or develop a new set of core, cross-industry semantics?
* Common Language - Common vocabulary, with a one to one correspondence between words and meaning.  ISSUE:  We may sacrifice this requirement in order to meet internationalization requirements.
* Common Character Encoding - This could be achieved by specifying that only UNICODE (or ASCII, or EBCDIC) be used.
* Common Presentation - Common set of XML attributes and common usage of those attributes, common approach to document structure.
* Common Security Implementations
* Common Data Transfer Protocol - For example, could be achieved by always using SMTP, or always using HTTP post and fetch.
* Common Network Layer - For example, TCP/IP instead of OSI or SNA.

Minimize Cost
------------------

* Acquisition - Cost of purchasing ebXML compliant applications
* Development - Cost to software vendors or large organizations of developing ebXML compliant applications.  In an ideal situation, this would also minimize cost of acquiring ebXML compliant applications.
* Deployment and Customization - Customization, in the form of mapping, is a major cost component of traditional EDI implementations.
* Integration - with business applications.  A major cost component of traditional EDI, but in the best case may be eliminated with ebXML support embedded in business applications.
* Operation and Support - Monitoring, problem resolution, adding new trading partners, staff training, etc.

Maximize Internationalization
-------------------------------------

Enable ebXML to be used in a user's native spoken language.  ISSUE:  Support all languages, or a limited set of common languages?  If a limited set, which ones?   NOTES:  There may be other requirements here as well, any ideas?   Note also that fulfilling this requirement may also tend to dictate a character encoding such as UNICODE that is capable of representing complex character sets.

Secondary Requirements
==================

Maximize Interoperability with existing EDI formats - ISSUE:  I don't propose this as a requirement, but list it here because I believe others have.  There are several issues with this, since UN/EDIFACT and ANSI X12 are not interoperable without considerable analysis on a case by case basis.  Making them both interoperable with a third set of semantics greatly increases the scope of the ebXML effort.   In addition picking just one or the other will be problematical for the community that uses the other standard.   As well, translating existing EDI semantics directly into XML can lead to some cumbersome XML.

Security - Of message exchange.   Composed of authentication of sender, message integrity, confidentiality, non-repudiation of receipt, non-repudiation of delivery.

Requirements of ebXML Guidelines
==========================

These address the requirements of those who will be implementing the guidelines by developing compliant software applications.

* Guidelines in Public Domain - No licensing fees to use guidelines.
* Freely Accessible Guidelines - Low cost (or free) publication, such as posting on the Internet.
* Clearly identify core, mandatory features and optional features.
* Flexible Usage- Enable a range of usage from using core features in ad hoc, informal exchanges at one end, to highly formal, structured exchanges derived from UML models on the other end.
* Scalable Implementation - Enable a range of implementations including a basic, low cost implementation with few or no optional features, appropriate for an SME, to comprehensive, complex implementations using all optional features appropriate to large enterprises.