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: Version 0.40 ebXML Requirements document


    Attached please find version 4.0 of the requirements document.  Please note
- some holes still exist, and additional proofing will be required before we
publically release.  

Mark Crawford
Research Fellow
LMI Logistics Management Institute
2000 Corporate Ridge, McLean, VA 22102-7805
(703) 917-7177   Fax (703) 917-7518
"Opportunity is what you make of it"

electronic business XML (ebXML)
 Requirements Specification
ebXML Requirements
Working Draft 18 February 2000
This version: 0.40 of 18 February 2000
 Latest version: 
 Previous version: 0.30 of 02 February 2000
Team Leader: Mike Rawlins 
Editor:  Mark Crawford
This ebXML Requirements Document represents the work of the ebXML Requirements 
Project Team.  It defines ebXML and the ebXML effort, articulates requirements for 
ebXML, and defines requirements that will be used by the various ebXML teams in 
preparing their deliverables.  
Status of this document 
This is an ebXML Requirements Project Team Working Draft for review by members of 
the ebXML work group and other interested parties in the general public.
It has been reviewed by the ebXML Requirements Project Team and the Requirements 
Project Team has agreed to its publication. Note that not that all sections of the draft 
represent the current consensus of the team. Different sections of the specification may 
well command different levels of consensus in the project team. Public comments on this 
draft will be instrumental in the project team's deliberations.
Please review and send comments to: ebXML-Requirements@lists.oasis-open.org 
Sections which the requirements team has reached consensus, are marked with an asterisk 
(*) at the end of the section title

1.2.1 	ebXML Vision
`	1.2.2	ebXML Scope
1.3.1	ebXML Requirements Document Purpose
1.3.2	ebXML Requirements Document Scope
2.3.1 	Multilingual
2.3.2 	Internationalization
2.4.1	 Registry and Repository
2.5.1 	Architecture
2.5.2 	Transport, Routing, & Packaging
2.5.3 	Compatibility with existing Tech & EB standards and practices
2.5.4 	Extensibility
2.5.5	Migration from existing EDI and XML solutions
2.7.1	Digital Signatures
3.1.1	General Task Group Requirements

1 Introduction
Electronic Business XML (ebXML) is an International Initiative established by UN/CEFACT and OASIS 
with a mandate to undertake a 15-18 month program of work. The purpose of ebXML initiative is to 
research and identify the technical basis upon which the global implementation of XML can be 
standardized. The goal is to provide an open technical framework to enable XML to be utilized in a 
consistent and uniform manner for the exchange of Electronic Business (EB) data in application to 
application, application to human and human to application environments thus creating a single global 
1.1 Documentation Conventions*
This ebXML Requirements Specification document was produced using Microsoft Word saved as MS-
DOS text with line breaks. The following highlighting is used for non-normative commentary in this 

              [Issue -]: A recorded issue. 

              [Ed. Note -]: Notes from the editors to themselves or the Working Group. 

              [NOTE -]: General comments directed to all readers.
1.2 ebXML Vision, Purpose, and Scope*
1.2.1 ebXML Vision*
The ebXML vision is to deliver:

"A single set of internationally agreed upon technical specifications that consist of common XML semantics 
and related document structures to facilitate global trade."

This single set of ebXML technical specifications will Create a Single Global Electronic MarketT.  To 
create this single global electronic market, this single set of ebXML technical specifications:

? is based on W3C XML technical specifications holding a recommended status.  
? provides for interoperability within and between ebXML compliant trading partner applications.
? maximizes interoperability and efficiency while providing a transition path from accredited EDI 
standards and developing XML business standards.
? will eventually be submitted to an appropriate internationally recognized standards body for 
consideration as an international standard.
1.1.2 ebXML Scope*
The ebXML initiative is targeted at every sector of the business community, from international 
conglomerate to small and medium sized enterprises engaged in business-to-business and business-to-
consumer trade. With that audience in mind, the ebXML initiative is committed to developing and 
delivering products that will be used by all trading partners interested in maximizing XML interoperability 
within and across trading partner communities.  
1.3 ebXML Requirements Document Purpose and Scope*
1.3.1 ebXML Requirements Document Purpose*
This document has two primary purposes.  The first of these is to provide clearly articulated requirements 
from representatives of international business and standards communities to assist the ebXML task group 
members in developing their deliverables in a consistent manner. This document is also intended to convey 
to interested parties the purpose, scope, and vision of ebXML.
1.3.2 ebXML Requirements Document Scope* 
This ebXML requirements document applies to the work underway within the current ebXML project 
teams.  Each project team has provided input to this document to ensure consensus with its contents.  In 
addition to the Requirements Project Team, project teams currently chartered by the ebXML steering 
committee are:
? Business Process Methodology
? Technical Architecture
? Core Components
? Transport/Routing and Packaging 
? Registry and Repository
? Technical Coordination and Support
? Marketing, Awareness and Education
1.4 References and Related Efforts
ebXML Terms of Reference (TOR) http://www.ebxml.org
UN/CEFACT Techniques and Methodologies Working Group Document ??
Customer Requirements for OO-EDI
1.5 General ebXML Principles
General ebXML principles to be followed in developing ebXML deliverables are to create technical 
specifications that:
? are simple, easy and ubiquitous,
? provide a global cross-industry open/interoperable standard for business-to-business and business-
to-consumer trade,
? coalesce the structure and content components of divergent XML standards into a single useable 
XML business standard,
? provide impetus so that common resources currently engaged in short-term solutions shall be 
marshaled to reach a common long-term solution goal, 
? support vertical and horizontal segments of industry and business participants,
? avoid imposing financial or software requirements constraints on ebXML users to buy, install or 
programmatically support any ebXML unique software products in the conduct of business 
information exchange,
? minimize cost of application-to-application exchanges, 
? meet the needs of all nationalities that use it,
? provide multi-lingual support
? accommodate national trade requirements
[Ed. Note - perhaps nationalities and multi-lingual support]
? provide a migration path from accredited EDI and developing XML business standards, and 
? apply when possible the simplification principles of SIMAC (document 
2 Business Requirements
This section describes the business requirements for business to be conducted electronically over a 
network.  The requirements are oriented toward using XML for electronic business, but most of the 
requirements are applicable to implementation with other technologies. 

The scope of ebXML business requirements is generally to meet the needs for the business side of both 
business to business and business to consumer activities.  Consumer requirements of the B2C model are 
beyond the scope of the ebXML technical specifications. 

[NOTE - for ease of reading, the term business is to be interpreted as interchangeable with for-profit, non-
profit, not-for profit, and government entities.]

The business requirements to be addressed by the ebXML initiative are divided into seven core areas - 
General Business, Electronic Business, Globalization, Accessibility, Usability/Interoperability, Security 
and Legal, and Organizational.  Each of these requirements is identified in the following sub-sections.
2.1 General Business Requirements
Business has a real need to use new technology with minimized investment to gain competitive advantage.  
The advent of the Internet and World Wide Web has proven to offer such benefits.  However, these benefits 
are in need of functionally neutral standard method of moving data. Specifically, business needs a solution 
that provides -
? a single, consistent approach to using XML for electronic business processes in both the B2B and 
B2C environments,
? support for both vertical and horizontal solutions regardless of the sophistication of the user,
? support for a range of implementations from basic, low cost appropriate for Small or Medium 
Enterprise (SME) deployment, to comprehensive, complex implementations using all optional 
features appropriate to large enterprises,
? 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
? support for current business models and practices as well as new ones developed through UML 
? a superset business process meta model that supports individual business process models
? a general specification for developing XML based schematas, 
? syntactically neutral core components that can be used regardless of the underlying syntax,
? XML syntax based core schematas and tags to support individual trading partner business 
processes that -
- eliminate duplication of effort 
- Provide support for XML metadata, such as the ebXML version/release and information 
corresponding to the EDI interchange headers. 
- Clearly identify core, mandatory features, and optional features
- provide a mechanism for full specification of the document semantics.
? a single recognized international standards organization to oversee responsibilities identified in 
items 1 and 2,
? an open development process with no barriers to entry, 
? open, readily accessible technical specifications and standards, and
? a solution that minimizes costs for development, maintenance, and use. 
[NOTE - Business looks to XML as a means of gaining competitive advantage through leveraging new 
technology.  Minimizing the cost of doing business electronically is a key element in achieving a 
competitive advantage.  The cost of doing business electronically can be grouped into acquisition, 
development, deployment and customization, integration with business applications, and operations and 
support.  It is expected that using XML for electronic business will be less costly than traditional forms of 
EDI and other existing electronic commerce technologies in each of these areas.  This expected cost 
reduction is a driving force for considering XML over traditional EDI technologies.]
2.2 Conducting Electronic Business using ebXML
Business applications must be able to exchange structured business documents (encoded in XML) with a 
corresponding application of another enterprise to support a business process.  This exchange may either be 
completely without human intervention, as is the case with traditional EDI, or with some level of human 
intervention to correct missing or erroneous data.   Business applications may also need to exchange 
structured business documents with intermediaries such as portals and brokers. To accomplish these 
requirements, it is critical to have syntax neutral core components that define classes within objects, a 
modeling methodology and meta-model to ensure interoperability between different groups of trading 
partners, and information exchange mechanisms that provide for plug and play, shrink wrapped, 
syntactically neutral schemata's.  Additionally, business applications must also: 
? Be able to generate XML encoded business documents that may be displayed using a specific 
presentation format, such as the appropriate U.N. Layout Key or a trading partner specified format.
? Enable data entry of business documents using a specified presentation format, such as the 
appropriate U.N. Layout Key or a trading partner specified format. The data entry shall result in an 
XML encoded document representing the business information.
2.3 Globalization
Globalization is critical in today's ever expanding marketplace.  The underlying purpose of ebXML is to 
facilitate international trade.  To achieve "a single global market" that such facilitation implies, it is critical 
to simplify existing exchange standards methodologies and harmonize divergent approaches.  This 
simplification and harmonization can be achieved through developing a business meta-model in 
conjunction with syntax neutral core components.  Both of these deliverables should accommodate 
divergent national and multi-national process requirements, and should support forward and backward 
compatibility with the developing ebXML technical framework.  To simplify development efforts, all work 
should use English. To support globalization, all ebXML technical specifications will be translatable into 
the other official UN languages- French and Russian. Translation into other languages will be the 
responsibility of the intended user, although such translations should be supported in the ebXML 
repository.  Regardless of language, and in keeping with the requirements of XML 1.0, all work will be 
compliant with Unicode and ISO/IEC 10646 for characters, Internet RFC 1766 for language identification 
tags, ISO 639 for language name codes, and ISO 3166 for country name codes.
2.4 Accessibility
Openness is a critical aspect of ebXML.  Business requires the ability to easily access ebXML technical 
specifications without regard to "membership", or payment of access and/or use fees.  This accessibility 
must be completely open to all potential users so as to eliminate the barriers for entry.  This accessibility, or 
openness, requires several key components to ensure viability.  Chief among these is an open, easily 
accessible registry and repository for the ebXML technical specifications.
2.4.1 Registry and Repository
A repository is required for storage, retrieval, and registration of various items that support performing 
business electronically.   There are two distinct sets of business requirements on the repository: a set 
dealing with managing the workflow of developing standard components that are stored in the repository, 
and a set dealing with application usage of the repository. If ebXML is to exist beyond its initial 18-month 
timeframe, then ebXML should maintain responsibility for ebXML technical specifications in an ebXML 
managed repository.  However, if the decision is made that ebXML will not exist after the initial set of 
deliverables, then ebXML must determine if the repository should transition to CEFACT, OASIS, 
XML.ORG, BizTalk, or some other existing XML business standards repository
2.5 Usability/Interoperability
2.5.1 Architecture
This is a primary requirement of the ebXML initiative. To maximize interoperability, the following 
requirements must be met.  As with other non-functional requirements, some aspects of achieving 
interoperability may conflict with other non-functional requirements.    Where a requirement is not met, 
software can usually be developed to provide a bridge.  However, such bridges may increase costs of 
development, implementation, or both, and conflict with cost minimization.  In other cases, achieving 
interoperability enhances other requirements.  For example, maximizing interoperability helps to achieve 
platform independence.
? Common Business Process - Both entities involved in the exchange of data must be engaged in 
executing the same transaction as part of a business process. 
? Common Semantics - Common meaning, as distinct from words, expression, or presentation.
? Common Language - Common vocabulary, with a one to one correspondence between words and 
meaning.  Also, a common spoken language
? Common Character Encoding [Note: UNICODE, which is specified in the XML specification, 
provides this.]
? Common Expression - Common set of XML element names, attributes and common usage of those 
attributes, common approach to document structure.
? Common Security Implementations
? Common Data Transfer Protocol
? Common Network Layer
2.5.2 Transport, Routing, & Packaging
Any exchange of business information requires fully described transport, routing, and packaging 
methodologies. These descriptions should be based on a program language independent definition of the 
service interface required for systems to control the messaging system for the purpose of sending and 
receiving messages.  These descriptions should identify the behavior of the messaging system required to 
realize reliable secure sending and receiving of messages over the internet, support for syntax neutral 
definition of the information that needs to be held in the supporting messaging policy repository, and 
details the format and structure of the wrapper, header, and any other data within the message - to include 
signatures and encryption.
2.5.3 Compatibility with existing Technology and EB standards and practices 
(W3C, RosettaNet, accredited EDI standards, etc.)
Businesses already have in place extensive EDI architectures and business solutions based on accredited 
EDI standards.  Additionally, many businesses are implementing XML solutions that are based on the 
technical specifications issued by the World Wide Web Consortium (W3C) and the XML based business 
standards of various competing XML standards like organizations.  Although the ebXML solution will 
facilitate a single global market, and although its technical framework will provide a single set of technical 
specifications, businesses will require the ability to inter-operate their existing EDI and XML solutions 
with solutions built on the ebXML framework.    

As part of compatibility, businesses require a technical framework that reuses common elements regardless 
of syntax.  To ensure a syntax neutral solution, ebXML must identify and define those items considered 
common across XML business data exchanges. Common items are  semantic units at any level that stay 
consistent across contexts, and  therefore are reusable both within and between business exchange 
messages.  Business process models will help define common items and provide their context. This context 
will in turn define the precise use of common items in messages exchanged among parties. ebXML should  
describe these items in  terms independent of implementation syntax, and thus should apply equally  to 
XML (or SGML) documents, as well as EDI transactions. EbXML should adopt -- or if needed, develop -- 
a methodology to  consistently build or derive core components, including methods to encourage reuse and 
provide for extensions. ebXML should identify element names that can apply  across business processes 
and contexts, yet still allow for translation  into leading spoken languages. ebXML work will generate the 
content of core  components independent of implementation syntax, but with references to  data structures 
in XML messages and EDI transactions. ebXML will identify attributes that describe the context of the 
components also in terms independent of syntax. 

[Ed. Note - the above paragraph was lifted (with slight modification) from the core components draft scope 
statement of 2/18/2000]
2.5.4 Extensibility
Businesses seek solutions that provide for a certain level of customization beyond core standards.  This 
extensibility is necessary to ensure internally unique business process requirements can be addressed 
beyond the scope of standards used for information exchanges between businesses.  EbXML must ensure 
extensibility is facilitated.
2.5.5 Migration from existing EDI and XML solutions
Businesses seek maximum interoperability between their applications and trading partner applications.  
This can be achieved by a single way of doing business electronically, i.e., a single standard for using XML 
for electronic business.  However, many also have a considerable investment in existing standards based 
EDI and emerging XML business approaches.  These businesses require a mechanism and migration path 
for accommodating legacy EDI solutions based on accredited standards and XML solutions already in 
progress or implemented. Although migration from existing EDI and XML solutions is a key element of 
ebXML, the ebXML solution will ensure maximizing interoperability takes precedence in developing the 
ebXML technical specifications.  Further, it is beyond the scope of the ebXML initiative to develop 
specific migration and transformation methods.
2.6 Security 
Aspects of security may be required at both a session layer (i.e., for the duration of a network session in 
which data is exchanged) or be applied to a single, stand-alone document instance. In addition, application 
of security to a particular exchange or document instance must be determined by the business needs, and 
allow unrestricted and unsecured interchanges as the default.  All, some, or no security features may be 
required in any particular exchange of business information.  Additionally, the following requirements must 
be addressed - 
? Confidentiality - Only sender and receiver can interpret document contents
? Authentication of sender - Assurance of the sender's identity.
? Authentication of receiver - Assurance of the receiver's identity.
? Integrity - Assurance that the message contents have not been altered.
? Non-repudiation of Origin - The sender can not deny having sent the message.
? Non-repudiation of Receipt - The receiver can not deny having received the message.
? Archiving - It must be possible to reconstruct the semantic intent of a document several years after 
the creation of the document.  This time period is subject to the archiving and record retention 
requirements of particular situations.  In general, businesses might require archiving and retrieval 
of up to 30 years after document creation. 
2.7 Legal
In many respects, legal requirements are duplicative of security requirements.  Beyond the security 
requirements identified in section 2.6, the following additional legal requirements exist -
? Comply with the requirements of UN recommendation 14 for signatures
? Provide versioning support to facilitate reconstructing the semantic meaning of transactions in 
accordance with the underlying transaction format used.
? Ensure metadata solutions do not result in legal issues.
? ensure all transmitted data is well-defined by a minimal set of metadata.
? ensure a mechanism provides for identifying completeness of a transaction.
2.7.1 Digital Signatures
? electronic transactions must provide for digital signatures at an appropriate level within the 
transaction to meet requirements of both the sender and receiver.
2.8 Management
2.8.1 Organizational Structure
The ebXML initiative is an eighteen month effort to develop a technical framework.  To ensure efficiency 
of operation and success in achieving the ebXML vision, sufficient organizational controls must be put in-
place as quickly as possible.  Further, there exists the possibility that ebXML will become more than a 
short term initiative.  As such, long term requirements for managing ebXML must be defined and 
addressed in the near term to ensure a smooth transition from short to long term management.  Further, if 
such a long term organization becomes reality, processes must be adopted for recasting ebXML as an 
internationally accredited standards body.
2.8.2 Participation
The ebXML initiative relies heavily on technical expert participation.  This participation must be free of 
organizational requirements that restrict or otherwise inhibit participation of anyone.  Further, participation 
should be limited to the individual and not at the organizational level.  This will ensure each technical 
expert is given an equal footing in the organization, management, and work effort of ebXML.  

3 ebXML Technical Framework Requirements
This section identifies specific requirements for achieving the ebXML technical framework through the 
work of each of the ebXML task groups.  These requirements have been developed in close coordination 
with those task groups to ensure consensus on their content.  These high level requirements are closely 
aligned with the business requirements in section two of this document and are consistent with the vision, 
purpose, scope and guiding principles contained in section one. These high level requirements are carefully 
designed to provide a road map for the respective task groups as they drill down to more detailed 
requirements in preparation for developing their ebXML deliverables. As each of these deliverables 
becomes a reality, they will contribute to the developing ebXML technical specifications as part of building 
the ebXML end state. 
3.1 General Requirements
General requirements, in conjunction with the business requirements stated in section two, are more 
detailed requirements that apply across the various task groups. These include all requirements necessary to 
achieve the technical architecture shown in figure 3-1.

Figure 3-1 ebXML Technical Framework

At a general requirements level, it is also important to define how each of the functional components of 
figure 3-1 will interact to form the basis for determining ebXML compliance for both implementations and 
transactional exchanges. Figure 3-2 illustrates this requirement, and in conjunction with figure 3-1 
graphically illustrate general technical requirements to be addressed by each of the ebXML task groups. 
3.1.1 General Task Group Requirements
Deliverables for each of the task groups must:
? be developed in compliance with the purpose, scope, and guiding principles identified in Section 1,  
? meet the business needs articulated in section two,
? facilitate the general requirements in section 3.1
? support the requirements of each task group as identified in the following subsections

Figure 3-2. ebXML compliance requirements

3.2 Requirements Task Group
The Requirements Task Group's initial task was to produce this ebXML requirements document.  In 
addition, the Requirements Task Group will:
? develop follow-on requirements documents in support of the ebXML Executive Committee and 
ebXML Steering Committee that meet the requirements contained in section 4 of this document.  
? review, evaluate, and assimilate follow-on requirements submitted by external organizations for 
consideration by ebXML
? provide assistance as required to the Technical Coordination and Support Task Group on 
requirements issues
3.3 Business Process Task Group
The Business Process Task Group detailed requirements and deliverables will -

? provide a high-level business process methodology in terms of XML, i.e., DTD.
? select a methodology with which to specify "vertical" business processes according to a uniform 
"template" (i.e., ebXML "superset") to support comparison.
? explicitly specify the ebXML "superset" business process meta-model. In no instance shall this 
meta-model be subject to implied specification using instantiations or derivations.
? incorporate cross-industry methodologies for specifying business processes, e.g., Open 
Applications Group (OAG), RosettaNet, HL7, into the ebXML "superset."
? specify reusable objects.
? create a glossary of terms related to business process methodology: vocabulary, e.g., functional, 
non-functional, vertical, message, segment, data type shall be created and maintained using TMWG 
Unified Modeling Methodology document Annex 1 as a start.
? create a glossary of terms specific to each business process to be modeled.
? create a glossary of XML tags.
? work with the Registry and Repository Task Group to incorporate technical specifications, models, 
and required glossaries into the ebXML repository. 
3.4 Technical Architecture Task Group
The Technical Architecture Task Group detailed requirements and deliverables will -
? Provide for naming conventions for technical and business content in the technical architecture

3.5 Core Components Task Group
The Core Components Task Group detailed requirements and deliverables will -
? be syntax independent, i.e., not specifically aligned with any existing syntax based semantics such 
? be defined to insure separation of common "fundamental" versus "extra" specific
? respect ISO 11179 rules

[Ed. Note  - do we accept this requirement? What is the impact of limiting ebXML to ISO 11179 rules?]

? use semantics solutions that accommodate currently defined accredited EDI semantics where they 
add value.
? use a single consistent set of terminology.
In achieving these deliverables, the Core Components Task Group will -
? liaison with the Business Process Team regarding development of business process models that 
identify potential reusable components. The business process team should develop the models that 
define and describe business semantics, but still point out those semantics with potential for 
reusability across messages.
? liaison with the Technical Architecture Team regarding Description of the overall framework and 
conventions for expressing core components in XML messages both in the business and technical 
content. For business content, the technical architecture team should distinguish  between common 
and business-specific components, if such a distinction is needed. The overall architecture for data 
exchange will need flexibility to meet the demands of Web customers, yet still need to support 
known business application and integration requirements as systems and tools mature.
? liaison with the Transport, Packaging, and Routing Team regarding description of common items 
used in message  headers, security features, transport protocols, and error messages. While  some 
core components may appear in transport, packaging, and routing  operations, these messages will 
likely have specific syntax and invocation  requirements that will require separate processing from 
the normal message  body.
? liaison with the Registry and repository team regarding specifications for submission and retrieval 
of core components in repositories. The registry and repository team should  describe the processes 
and methods for the identification or registration of core components in repositories.
3.6 Transport/Routing and Packaging
The Transport/Routing and Packaging Task Group detailed requirements and deliverables will -
? Specify how to envelope business documents in regard to:
- Related messages in a collection
- Physical and/or logical addressing of destination for messages
? Specify exchange at the application level
? Specify wire format mapping 
? provide for flexible transaction boundaries
? provide for reliable messaging and error handling
? identify messaging routing
? meet security requirements
? provide for audit trains
? define and meet acceptable levels of quality of service
? support platform independent interoperability
? support restart and recovery
[NOTE - Some applications could make use of the caller (client) being able to own and demarcate 
traditional transaction boundaries, either across trading partner ("servers") or across a single trading partner 
("server").  However, other applications (such as in the Travel industry) require a model that facilitates a 
"verify and <action>" model that does not require the client to explicitly own any transaction 

3.7 Registry and Repository Task Group

The Registry and Repository Task Group detailed requirements and deliverables will -
? identify the long term maintainer of this repository
? develop detailed blueprints for an ebXML repository that 
- uses open management processes
- has open access
- has interfaces with other existing and planned XML business standards repositories
- accommodates:
? Versioning
? Metadata Registry
? Model interchange (UML - XML schemas)
? tool to tool queries and exchanges
? repository to repository queries and exchanges
? tool to repository queries and exchanges
? repository to tool queries and exchanges
- enables model integration (e.g., how to create an XML schema from a UML diagram and vice-
versa without loss or gain), 
- supports Web access
- includes
? a glossary of terms related to business process methodology: vocabulary, e.g., functional, 
non-functional, vertical, message, segment, data type  using TMWG Unified Modeling 
Methodology document Annex 1 as a start 
? a glossary of terms specific to each business process to be modeled 
? a glossary of ebXML semantic tags
? archives of previous ebXML technical specifications.
? archives of previous ebXML technical specifications
- supports legacy information, including historical EDI directories (X12, UN/EDIFACT, etc.) 
- stores a legacy data model (e.g., IDEF-1X) and retrieves it back out as a UML class diagram 
- stores 100% of a UML model (OCL, use cases, state diagrams, interaction diagrams, etc.) and 
retrieves it back out in its entirety.
- enables businesses to interactively map internal application semantics to horizontal and vertical 
industry semantics (semantic equivalent mappings). 
- identifies data context with respect to where it is being used in the business process. 
- supports change or enhancement to an as a result of implementation issues. 
- supports exact and fuzzy search capabilities. 
- supports electronic work item proposals in any format. 
- identifies all the vertical domains for each artifact (UML classes, XML declarations). 
- differentiates work in progress to that which is an actual standard. 
- supports existing software and standards that are already in place. (reuse-buy-build principle) 
- ensures changes in repository content is restricted to authorized individuals.
- ensures access is restricted as necessary
- provides predictable naming conventions based on a formal scheme. 
- provides predictable version identifiers based on a formal scheme.
- provides dynamic mapping tools that automatically retrieve the most current file specification 
from a repository.
- supports real time file specification retrieval to understand how to correctly parse a file and write 
out a conformant file. 
- identifies which trading partners are capable of engaging into a given electronic business 
- identifies which trading partners provide certain products and services. 
- identifies what networking schemes must be used to physically communicate with a trading 
- facilitates discovery by intelligent information agents. 
- supports Internet 24x7 access. 
- has repository performance levels that support real-time interaction with business applications 
3.8 Technical Coordination and Support
The Technical Coordination and Support Task Group detailed requirements and deliverables will address -
? Project Team output consistency
? Research both internal and external XML concepts and technologies in support of executive 
committee and project team requirements
? outreach requirements and recommendations
? a clear definition of ebXML compliance
3.9 Marketing, Awareness and Education
The real success for ebXML will be in its adoption by the business community.  To help facilitate that 
adoption, the Marketing, Awareness and Education Project Team must ensure the business community is 
aware of 

? The contents of this requirements document
? The efforts of the various ebXML project teams
To achieve this awareness, the Marketing, Awareness and Education Project Team will develop 
requirements and deliverables that address -
? marketing and promotion of ebXML
? recruitment of expanded participation by relevant bodies, companies, organizations, and other 
entities involved in EDI and XML development, standardization, and deployment
? awareness and education of ebXML technical specifications
4 ebXML Organizational and Procedural Requirements
The ebXML Work Group organization is best defined by figure 4-1.  This figure shows a schematic of 
interactions and how the process derives technical specifications. 

This figure also provides the basis for developing organizational and procedural requirements.  The ebXML 
executive committee must put in place organizational and procedural processes as soon as possible.  These 
organizational and procedural processes are critical to enable the various ebXML task groups to make 
sound decisions in developing their requirements and deliverables.  These organizational and procedural 
processes must 

? facilitate the efforts of the Requirements and Technical Coordination and Support Project Teams
? support each of the functional project teams to meet their requirements

In developing these organizational and procedural processes, they will
? follow the purpose, scope, and guiding principles identified in Section 1,  
? meet the business needs articulated in section two,
? facilitate the general requirements in section 3.1
? support the requirements of each task group as identified in section 3.
These organizational and procedural processes must provide for

? an open and consensus driven ebXML management process 
? an open, timely, and consensus driven ebXML products development process that 
-  is responsive to business needs
- has sufficient controls to prevent creation of equivalent components 
? an open, timely, and consensus driven ebXML technical specifications approval process that is 
responsive to business needs. 
Additionally, the Executive and Steering Committees, in conjunction with the full ebXML Work Group 
must determine: 

? the requirements for short and long term ebXML relationships with CEFACT, W3C, ANSI, ISO 
and other standards bodies
? the requirements for short and long term ebXML relationships with OASIS, BizTalk, 
CommerceOne, RosettaNet, and other XML business standards bodies must be defined 
? the appropriateness of moving ebXML technical specifications to recognized international 
standards under the cognizance of an international standards body
? who will be the single body that is responsible for long term maintenance of the ebXML technical 
specifications, repository, and supporting mechanisms -  OASIS, UN/CEFACT, or ebXML.
? the process for long term maintenance of the ebXML technical specifications 
? ebXML funding methodology 
? Measures of success 
5 ebXML Task Group Deliverables
This section identifies the nature of ebXML Work Group deliverables to guide each work group in 
developing those deliverables.  These high level deliverables descriptions are intended to facilitate the 
efforts of the Technical Coordination and Support Project Team in ensuring consistency in the output of 
the various functional project teams.  These high-level deliverables descriptions are identified in figure 5-1.

Figure 5-1. ebXML Task Group


Project Team Business 

What is the contribution of your 
group to ebXML?

Picture Model of Your Project 
Team Deliverables

Business Method - How your 
deliverables will be used

To assist in visualizing the above figure 5-2 is a conceptual model of overall ebXML stack interactions

Business Applications and Delivery Systems 
(external to ebXML)
Business Process Methodology
Core Components
Registry and Repository
Transport/Routing and Packaging
Technical Architecture

Technology Base (external to ebXML)

Executive Committee
Steering Committee
Technical Coordination and Support
Work Flow
Administration / Marketing

To ensure consistency across all deliverables, each project team will use the format of this requirements 
document to prepare all deliverables.

ebXML Requirements Specification Version 0.40 of 18 February 2000	9

ebXML Requirements Specification Version .htm

ebXML Requirements Specification Version .doc

[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