http://www.ebxml.org/specdrafts/Reqspc06.htm; use this URL/document if possible.]
electronic business XML (ebXML)
ebXML Requirements Specification
of 18 February
Previous version: 0.
40 of 1 8
Team Leader: Mike Rawlins
Editor: Mark Crawford
ebXML Requirements Specification
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
is an ebXML Requirements Project Team
Working Draft for review by members of the ebXML
and other interested parties in the general public.
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.
review and send comments to:
Sections which the r equirements t eam has not yet reached consensus, are marked with an
asterisk (*) at the end of the section title.
1.1 Documentation Conventions
The ebXML Vision, Purpose, and Scope
1.2.1 ebXML Vision
` 1.2.2 ebXML Scope
Document Purpose and Scope
and Related Efforts
2 Business Requirements
2.1 General Business Requirements
2.2 Conducting Electronic Business using ebXML
2.3.1 Multilingual 2.3.2 Internationalization
2.4.1 Registry and Repository
2.5.2 Transport, Routing, & Packaging
188.8.131.52 Compatibility with existing Tech & EB standards and practices
2.5.4 Extensibility 2.5.5 Migration
from existing EDI and XML solutions
2.7 Legal 2.7.1 Digital Signatures
3 ebXML TECHNICAL FRAMEWORK Requirements
3.1 General Requirements
3.1.1 General Project Team Requirements
3.3 Business Process
3.4 Technical Architecture
3.6 Transport/Routing and Packaging
Coordination and Support
3.9 Marketing, Awareness and Education
ebXML Organizational and Procedural
5 ebXML Project Team Deliverables
(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 market
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 document:
[Issue -]: A recorded issue.
[Ed. Note -]: Notes from the editors to themselves or the Working Group.
[NOTE -]: General comments directed to all readers.
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 Market
. To create this single global
electronic market, this single set of ebXML technical specifications :
is fully compliant with 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 be submitted to an appropriate internationally recognized standards body for accreditation as an international standard.
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.
has two primary purposes.
The first of these is to provide clearly articulated requirements from
representatives of international business and accredited standards
organizations to assist the ebXML project team 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
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:
¨ Technical Architecture
¨ Core Components
¨ Transport/Routing and Packaging
¨ Registry and Repository
¨ Technical Coordination and Support
¨ Marketing, Awareness and Education
Recommendations for ebXML Kickoff Meeting - UN/CEFACT/TMWG/N104
United Nations Layout Key for Trade Documents, Recommendation No. 1, second edition, adopted by the Working Party on Facilitation of International Trade Procedures, Geneva, March 1981 Source: ECE/TRADE/137
Authentication of Trade Documents by Means Other Than Signature, Recommendation No. 14, second edition, adopted by the Working Party on Facilitation of International Trade Procedures, Geneva, March 1979 Source: TRADEWP.4/INF.63
Information technology -- Specification and standardization of data elements, International Organization for Standardization (ISO)/ International Electrotechnical Commission (IEC) 11179
Customer Requirements for the Next Generation of EDI Standards - CEFACT/TMWG/N027 CEN/ISSS
XML/edi Initiative http://cen.isss.org
General ebXML principles to be followed in developing ebXML deliverables are to create technical specifications that:
simple, easy and ubiquitous use of XML for electronic business ,
a global cross-industry open/interoperable standard for business-to-business
and business-to-consumer trade ,
the structure and content components of divergent XML standards into a single
useable XML business standard ,
impetus so that common resources currently engaged in short-term solutions
shall be marshaled to reach a common long-term solution goal ,
vertical and horizontal segments of industry and business participants ,
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 ,
cost of application-to-application exchanges ,
needs of all nationalities that use it ,
national and international trade requirements
a migration path from accredited EDI and developing XML business standards ,
when possible the simplification principles of SIMAC (document
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
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.
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 ,
for both vertical (e.g. industry, functional, organizational) and horizontal
(e.g. cross-industry, multi-functional, organizationally neutral) solutions
regardless of the sophistication of the user ,
for a range of implementations from basic, low cost solutions appropriate for
Small or Medium Enterprise (SME) deployment, to comprehensive, complex
implementations using all optional features appropriate to large enterprises,
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
for current business models and practices as well as new ones developed through
business process modeling,
superset business process meta model that supports individually developed
business process models,
general specification for developing XML based schemata's,
neutral core components,
¨ XML syntax based core schemata's 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 existing EDI standards interchange headers
- clearly identify core, mandatory features, and optional features
- provide a mechanism for full specification of semantic meaning
recognized international standards organization to oversee responsibilities
identified in items 1 and 2,
development process with no barriers to entry ,
readily accessible technical specifications and standards , and
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.]
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 solutions. 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 for Trade Documents or a trading partner specified
Enable data entry of business documents using a
specified presentation format
, such as the appropriate U.N. Layout Key for
Trade Documents or a trading partner specified format. The data entry shall
result in an XML encoded document representing the business information.
Globalized solutions are 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 shall 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.
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.
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 supported repository. However, if the decision is made that ebXML will not exist after the initial set of deliverables, then ebXML must determine if repository oversight responsibilities should transition to CEFACT, OASIS, XML.ORG, BizTalk, or some other existing XML business standards organization.
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 in the context 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
¨ 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
Any exchange of business information requires fully
described transport, routing, and packaging methodologies. These descriptions
should be based on a program language definition independent 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
reliable secure sending and receiving of messages over the internet
syntax neutral definition of the information that needs to be held in the
supporting messaging policy repository , and
the format and structure of the wrapper, header, and any other data within the
message - to include signatures and encryption .
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.
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 groups. 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 still 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.
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 businesses 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.
is beyond the current scope of the ebXML initiative to develop specific
migration and transformation methods.]
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.
In many respects, legal requirements are duplicative of
security requirements. Beyond the
security requirements identified in section 2.6, the following additional legal
¨ Comply with the requirements of UN/CEFACT recommendation 14 - Authentication of Trade Documents by Means Other Than Signature
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
add lead in
for digital signatures at an appropriate level within the transaction to meet
requirements of both the sender and receiver.
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.
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.
This section identifies specific requirements for achieving the ebXML technical framework through the work of each of the ebXML project teams. These requirements have been developed in close coordination with those project teams 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 project teams 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.
requirements, in conjunction with the business requirements stated in section
two, are more detailed requirements that apply
to each project team. These include all requirements necessary to achieve the
technical architecture shown in figure 3-1.
Figure 3-1 ebXML Technical Architecture
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 project teams.
Deliverables for each of the project teams 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,
¨ clearly identify core, mandatory features, and optional features, and
¨ support the requirements of each project team as identified in the following subsections.
Figure 3-2. ebXML compliance requirements
The Requirements Project Team's initial task was to produce this ebXML requirements document. In addition, the Requirements Project Team 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 .
evaluate, and assimilate follow-on requirements submitted by external
organizations for consideration by ebXML
assistance as required to the Technical
Coordination and Support Project Team on requirements issues
The Business Process
Project Team detailed requirements and deliverables will
a high-level business process methodology in terms of XML, e.g., DTD .
methodology with which to specify "vertical" business processes
according to a uniform "template" (i.e., ebXML "superset")
to support comparison .
specify the ebXML "superset" business process meta-model. In no instance
shall this meta-model be subject to implied specification using instantiations
or derivations .
cross-industry methodologies for specifying business processes, e.g., Open
Applications Group (OAG), RosettaNet, HL7, into the
ebXML "superset ."
reusable objects .
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 .
glossary of terms specific to each business process to be modeled .
glossary of XML tags .
language neutral mechanisms for associating business vocabularies to repository
semantic definitions .
w ork with the Registry and
Repository Project Team to incorporate technical specifications, models,
and required glossaries into the ebXML repository .
Architecture Project Team
detailed requirements and deliverables will
naming conventions for technical and business content in the technical
The Core Components
Project Team detailed requirements and deliverables will
be syntax independen t ,
defined to insure separation of common "fundamental" versus
where appropriate ISO/IEC 11179 rules ¨
semantics solutions that accommodate currently defined accredited EDI semantics
where they add value .
single consistent set of terminology .
and Packaging Project Team detailed requirements and deliverables will
Specify how to envelope business documents in regard to
messages in a collection
and/or logical addressing of destination for messages
¨ Specify exchange at the application level
common mapping techniques
¨ Provide for flexible transaction boundaries
¨ Provide for reliable messaging and error handling
¨ Identify messaging routing
¨ Meet security requirements
¨ Provide for audit trails
¨ 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 demarcations.]
The Registry and
Repository Project Team detailed requirements and deliverables will
maintainer of this repository
Develop detailed blueprints for an eb
- uses open management processes
- has open access
- has interfaces with other existing and planned XML business standards repositories
interchange (e.g. UML - XML schemas)
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)
§ 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
- develops open XML based structures for storing information within a repository
- 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
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
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
- supports existing software and standards that are already in place. (reuse-buy-build principle)
ensures changes in repository content are restricted to
- ensures access is restricted as necessary
provides predictable naming conventions based on a formal
provides predictable version identifiers based on a formal
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 transaction
identifies which trading partners provide certain products and
identifies what networking schemes must be used to physically
communicate with a trading partner
facilitates discovery by intelligent information agents
supports Internet 24x7 access
- has repository performance levels that support real-time interaction with business applications
Coordination and Support Project Team
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
requirements and recommendations
definition of ebXML compliance
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
and promotion of ebXML
of expanded participation by relevant bodies, companies, organizations, and
other entities involved in EDI and XML development, standardization, and
and education of ebXML technical specifications
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 project teams to make sound decisions in developing their
requirements and deliverables. These
organizational and procedural processes must
the efforts of the Requirements and Technical Coordination and Support Project
each of the functional project teams to meet their requirements
In developing these organizational and procedural processes, they will
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 project team as identified in section 3.
These organizational and procedural processes must provide for
and consensus driven ebXML management process
timely, and consensus driven ebXML products development process that
- is responsive to business needs
- has sufficient controls to prevent creation of equivalent components
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
requirements for short and long term ebXML relationships with OASIS, BizTalk,
CommerceOne, RosettaNet, and other XML business standards bodies must be defined
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
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 Project Team
WHAT IT DOES
HOW ITS USED
Project Team Business Requirement
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
Registry and Repository
Transport/Routing and Packaging
Technology Base (external to ebXML)
Technical Coordination and Support
Administration / Marketing
To ensure consistency across all deliverables, each project team will use the format of this requirements document to prepare all deliverables.