[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: ebXML Requirements Version zero point two five
Greetings,
Attached file contains latest version of requirements document. I have
incorporated all requirements submitted since last friday in preparation for our
deliberations Tuesday.
Mark
Mark Crawford
Research Fellow
______
LMI Logistics Management Institute
2000 Corporate Ridge, McLean, VA 22102-7805
(703) 917-7177 Fax (703) 917-7518
mcrawfor@lmi.org
http://www.lmi.org
"Opportunity is what you make of it"
ebXML Requirements Specification
ebXML Requirements
Working Draft 31 January 2000
This version: 0.25 of 31 January 2000
Latest version:
Previous version: 0.20 of 27 January 2000
Team Leader: Mike Rawlins
Editor: Mark Crawford
Abstract
Status of this document
This is a ebXML Requirements 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 Team and the Requirements 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 team. Public comments on this draft will be
instrumental in the teams deliberations.
Please review and send comments to:
Sections which the requirements team has reached consensus, are marked with an asterisk
(*) at the end of the section title
EBXML REQUIREMENTS SPECIFICATION 1
VERSION 0.25 1
1 INTRODUCTION 2
1.1 DOCUMENTATION CONVENTIONS 2
1.2 THE EBXML INITIATIVE 2
1.3 DOCUMENT PURPOSE AND SCOPE 3
1.3.1 Purpose 3
1.3.2 Scope of ebXML initiative 3
1.4 REFERENCES AND RELATED EFFORTS 3
1.5 DELIVERABLES 3
1.6 GENERAL XML REQUIREMENTS AND IMPETUS FOR USE 3
1.7 GENERAL EBXML STANDARDS REQUIREMENTS 4
1.8 SUCCESS OF THE EBXML INITIATIVE 5
2 HIGH LEVEL REQUIREMENTS FOR AN EBXML COMPLIANT APPLICATION
ENVIRONMENT 5
2.1 GENERAL 5
2.2 FUNCTIONAL REQUIREMENTS 5
2.2.1 Application to Application - 6
2.2.2 Human to Application and Application to Human 6
2.2.3 Registry and Repository 6
2.2.4 Common Network Layer 6
2.3 NON-FUNCTIONAL REQUIREMENTS 6
2.3.1 Maximize Interoperability 6
2.3.2 Minimize Cost 7
2.3.3 Maximize Internationalization 7
2.3.4 Maximize Interoperability with existing EDI and XML Implementations 7
2.3.5 Security 7
2.3.6 Archiving and Legal 8
3 DETAIL REQUIREMENTS FOR AN EBXML COMPLIANT APPLICATION
ENVIRONMENT 8
3.1 REGISTRY AND REPOSITORY 8
3.1.1 Standards Development Workflow 8
3.1.2 Application level Usage 9
3.2 TRANSPORT AND ROUTING 9
4 EBXML GUIDELINE REQUIREMENTS 10
4.1 GENERAL 10
4.2 TECHNICAL ARCHITECTURE 10
4.3 CORE COMPONENTS 10
4.4 TRANSPORT/ROUTING AND PACKAGING 11
4.5 LEGAL 11
4.6 REGISTRY AND REPOSITORY 11
4.7 BUSINESS PROCESS METHODOLOGY 12
4.8 INTEROPERABILITY 12
5 EBXML ORGANIZATIONAL AND PROCEDURAL REQUIREMENTS 13
6 REQUIREMENTS FOR EBXML TECHNICAL COORDINATION & SUPPORT 14
7 REQUIREMENTS FOR EBXML MARKETING, AWARENESS & EDUCATION 14
8 EBXML WORK GROUP DELIVERABLES 14
8.1 INITIAL DELIVERABLES 14
8.2 FINAL DELIVERABLES 14
9 ADD TO GLOSSARY TERMS 15
1 Introduction
This document
[Ed. Note - Need some more verbiage here.]
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
document:
[Issue - ]: A recorded issue.
[Ed. Note - ]: Notes from the editors to themselves or the Working Gorup.
[NOTE - ]: General comments directed to all readers.
[Ed. Note - A member has stated " Don't need to mention done with MS Word." I disagree]
[Ed. Note - A member has stated "Add information on normative and informative sections". Require
clarification]
1.2 The ebXML Initiative Purpose and Scope
1.2.1 ebXML Purpose
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.
The ebXML business standards consensus building experts are working outside the boundaries of their
traditional EDI and XML standards environments (i.e. parochial X12/CEFACT/OASIS orientation) to
develop an international XML based standards solution to address the interoperability dilema being created
by the ever-expanding universe of industry or trading partner stovepiped XML Document Type Definitions
(DTDs) and schemas.
[Ed. Note - A member has suggested the following rewrite for the above paragraph -
" The ebXML initiative is intended to provide a set of specific XML based mechanisms and best practices
that can be adopted by the mainstream of industries to reach a broad global audience. The initiative is not
intended to replace such industry initiatives, rather to provide alignment and standard based systems to
bring what would otherwise be diverse incompatible systems together. Therefore ebXML is not a mandate
of rigid hardline rules, but rather a flexible, extensible system that integrates rather than replaces."
Do we keep the current paragraph, modify it, adopt the proposed replacement, modify it, or create a
hybrid?]
1.2.2 ebXML Scope
The scope of ebXML initiative is to develop and publish, in the public domain, relevant and open technical
specifications in support of domestic and international EB exchanges. These Terms of Reference cover:
* A definition of the specific technical issues to be addressed;
* A description of the proposed deliverables;
* Criteria for membership;
* The organization of the group;
* Target time scales and milestones for its deliverables; and
* A proposal for membership from other relevant groups and organizations.
1.3 Document Purpose and Scope
1.3.1 Purpose
The purpose of this requirments document is to provide clearly articulated requirements from international
business and standards communities to assist the ebXML task group members in developing their
deliverables in a consistent manner.
1.3.2 Document Scope
[Ed. Note - Do we need a document scope statement?]
1.4 References and Related Efforts
ebXML TOR
TMWG N???
Customer Requirements for OO-EDI
Others?
1.5 General Deliverables
In order to support the interoperability of XML based information exchanges in Electronic Business, the
ebXML initiative should provide the following deliverables:
* An analysis of the current EDI/EC/EB processes and issues;
* An assessment of the advantages and disadvantages of utilizing XML; and
* A definitive set of open technical specifications and recommendations that support the inter-operability of
XML based information exchanges in application to application, application to person and person to
application environments.
* Exchange business documents between applications (using XML)
[Ed. Note - A member has stated this requirement is not appropriate as users will be doing the document
exchanges. Do we agree with this assessment?]
1.6 General XML Requirements and impetus for use
XML is the de facto, standard, serialized vocabulary of the Internet, EC, Electronic Business (EB) and
Enterprise Resource Planning (ERP) - 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. The Business
users want XML because XML
? Moves them closer to a 100% paper-less operation.
? Provides one documents format for both browser and application-to-application computer application
? Moves them to cheaper web/ Internet solution
? it is a user oriented solution, does not require a programmer.
[Ed. Note - A member disagrees with this statement as written].
? It provides a migration path from traditional Electronic Data Interchange (EDI) to XML based EDI
? It provides a migration path from traditional EDI to Object Oriented (OO) XML/EDI
? It supports international and regulatory requirements as required in electronic business
[Ed. Note - A member has stated " This section strays seriously off the mark, and has recommended the
following alternative:
XML is the de facto semantic representation and vocabulary of choice for business information. XML is
particularly for use via Internet based delivery systems. XML is designed to be equally applicable in either
human operator interfacing environments or machine-only interfacing via fully automated formats.
In today's computer application systems this can be generalized to supporting:
? Moving to paperless business operations.
? Reaching a broad internet audience with limited resources and budgets.
? Supporting use by companies with a low-level of technology competence.
? Integration into today's existing business applications.
? Providing extensible mechanisms that enable new metaphors, processes and types of business
information interchanges.
? Ensuring ebXML syntax is developed within 15 months or sooner.]
However, business user do not want -
? To scrap existing EDI investment and operation
? To waste time waiting for the perfect XML solution
? To move to a new, single, complex e-solution which requires too much rethinking of business models
too soon.
? Divergent XML DTD developments (similar to EDI divergence)
[Ed. Note - A member has suggested rewriting the above to: " However, these goals should be achieved
without -
? Invalidating existing legacy EDI systems, operations and processes.
? Incurring undue delays in delivering workable XML business technologies.
? Attempting to impose a single overawing standard that cannot adapt and evolve.
? Failing to align and reign in the already rampant proliferation of incompatible XML
vocabularies and schemas.]
1.7 General ebXML Standards Requirements
General ebXML Standards Requirements are to:
? be SIMPLE, EASY and UBIQUITOUS
? Develop a cross-industry global standard
? Provide a global open /interoperable standard for specifying a document markup language based on
plain-text tags.
? 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
? Assess the impact of the current immaturity of various technical specifications on ebXML work in
both the short term and long term.
? Determine the impact of building ebXML business standards that use the various W3C technical
specifications as the underlying syntax when ebXML has no control over those specifications.
? Support both vertical and horizontal segments of industry and business participants and should not
impose any financial or software requirements constraints on the respective partners to buy, install or
programmatically support any software products in the conduct of business information exchange.
? facilitate
? Business to Business commerce
? Direct data interface to an XML compliant software without any translation or application
integration software effort
? Business to Consumer commerce Deliver business information exchanged to be viewed with a
browser or extracted for data interface within consumer partner system
[Ed. Note - this appears to be in conflict with section 2.1]
? Consumer to Business commerce Deliver response in XML to business information exchanged to
the Business partner for direct data interface to their XML compliant application.
[Ed. Note - this appears to be in conflict with section 2.1]
[Ed. Note - In response to this Ed. note, a member has stated "I don't understand precisely but think that
the C2B is an important aspect to ebXML. Is there a conflict?]
? minimize cost of application-to-application exchanges.
? meet the needs of all nationalities that use it.
? be defined and adopted by mid-year 2000.
? Provide a migration path from EDI to ebXML
[Ed. Note - a member has articulated the additive requirement of . Applying when possible the
simplification principles of SIMAC (document TRADE/CEFACT/1999/CRP.12 sent. Do we agree with
the requirement?]
? Provide a migration path from existing XML solutions to ebXML
[Ed. Note - A member has proposed the following rewrite for the above section - " OK - several threads
here that need to be better organized, also some statements that are flat-out wrong and therefore need
corrected.
The general ebXML standards requirements can be organized into several discrete groups, including:
global integration needs; user specific needs; legacy systems needs; and XML syntax related goals.
Detailing each of these in turn shows the following:
Global integration needs:
? Provide the means to accommodate differing language and semantic definitions
? Create a single consistent set of flexible mechanisms that can be used to support a wide
variety of uses.
? Create specific syntax mechanisms that can be adopted by a broad range of existing industry
schema efforts to enable interoperability between schemas and systems.
? Provide a set of interchange mechanisms based on XML so that machine-to-machine
interchanges can be implemented consistently.
User specific needs:
? Globally accessible re-usable set of methods and definitions that make using ebXML derived
components straightforward, simple and intuitive.
? Make ebXML methods easy to add into existing XML and EDI systems, without requiring
major changes, and with a minimal amount of syntax overhead.
? Provide extensible mechanisms so that systems supporting ebXML can easily be upgrade to
include future technologies.
Legacy systems needs:
? Provide the means to migrate legacy transactions and processes to new XML based systems.
? Retain the semantic base of legacy systems and provide the means to expose that legacy
semantics via an Internet based repository mechanism.
? Move legacy semantics toward a single consistent representation that accommodates a wide
range of legacy systems.
XML syntax related goals:
? Utilize XML syntax and parser systems to enable business information exchange.
? Preserve the existing basic XML syntax as much as possible, only utilize basic mechanisms,
and strongly resist basing ebXML implementations on exotic and complex extensions to basic XML.
? Provide recommendations on new and extended capabilities to existing basic XML syntax to
support exact ebXML syntax requirements that it is not possible to directly implement.
? Make business mechanisms in XML syntax that foster simple open software implementations
from software vendors.]
1.8 Success of the ebXML initiative
Define the measure of success for this initiative
2 High Level Requirements for an ebXML Compliant
Application Environment
2.1 General
This section describes the requirements for an application to be compliant with ebXML standards, and the
overall ebXML system environment in which it operates. These requirements are expressed at a high
level. Requirements are expressed in greater detail in section 3. Satisfying these requirements is primarily
the responsibility of software vendors. However, the requirements should guide ebXML standards
developers in creating guidelines that assist vendors in satisfying these requirements.
The scope of the requirements is generally for business-to-business activities (B2B). However, business-
to-consumer (B2C) activities are not specifically excluded. Requirements that are exclusively B2C are
beyond the scope of the ebXML guidelines.
[Ed. Note - an alternative statement might be - The scope of ebXML requirements is generally to meet the
needs for the business side of business to business (B2B) activities and business to consumer (B2C)
activities. Consumer requirements of the (B2C) model are beyond the scope of the ebXML guidelines. ]
[Ed. Note - A member has suggested that B2C requirements should only be "outside the main focus of the
initial release". This implies an expansion of the specifics of the components of this document. Do we
accept or reject this revised scope]
The requirements are expressed in three functional areas: application to application (EDI), human to
application, and registry/repository. A set of non-functional (or quality) requirements which may be
applicable to all of the functional areas are then listed. If unfamiliar with the distinction between
functional and non-functional requirements, please refer to the definitions for these terms in the glossary.
[Ed. Note - Do we accept the term EDI as meaning application to application? At least two members have
indicated agreement with this definition]
[Ed. Note - Is this the appropriate place for the matrix? At least one member has indicated yes]
2.2 Functional Requirements
[Ed. Note - a member has identified a number of functional requirements that do not appear in this version.
Should these be included or excluded -
Functional Requirements of an ebXML application
Messaging/Packaging
Envelope for routing of message content
Security (eg.: non repudiation, digital signature)
Guaranteed message delivery
Batch processing (multiple instances of one message type)
Related messages in a collection
Quality of Service]
[Ed. Note - a member has identified an overarching functional requirement that "there should be ONE and
ONLY ONE ebXML standard for software developers, business partners to adopt and should be free of
constraints such as Version Numbers to upgrade to or migrate to keep up to date. Each Version revision
should continue to support past revisions." Should this be added in this paragraph? Another member has
indicated his disagreement with this requirement, to wit - Definitely not! Versioning is an intrinsic part of
application system implementation. Just decreeing that it does not exist anymore is not a valid approach!
I'd prefer a statement that natural and lightweight versioning be built into ebXML. Versioning should
allow automatic agent based machine determined resolution of changes as much as possible. Versioning
should use simple existing XML syntax mechanisms." Yet another member has stated "this is not a
functional requirement. It is a statement of a deliverable, and a NFR for backward compatibility.]
[Ed. Note - This is an important issue, could we have more rational from the author of the issue to make up
my mind? We know in international trade that software companies want to sell more software why business
want to be able to get the cost benefits of their applications. We have the same issue in UN/EDIFACT as
companies in Europe use D96 version.]
[Ed. Note - a member has identified an overarching functional requirement that "Using ebXML defined
standards, any parsing software tool can extract content information exchanged between partners for
processing by the receiver's system while displaying other content in different ways for viewers. The
exchanged information in XML can also be viewed or displayed through available WEB browsers in the
marketplace." Should this be added in this paragraph? In response, a member has asked "Could we have
more rational to understand what is meant." Another member has stated "This seems wildly over detailed
for this section level. It would better be stated in the section on repositories, outlining detailed behaviours."
Another member has stated we should " Include under general functional requirements, but briefly. Like
EbXML compliant applications must be able to produce XML documents formatted according to ebXML
guidelines. These documents may be processed by a trading partner either in appoliction to application
mode (EDI), or viewed in an XML compliant browswer (human to application), depending on the trading
partner's choice.]
2.2.1 Application to Application -
An ebXML compliant application must be able to exchange structured business documents (encoded in
XML)
[Ed. Note - do we want to exchange at the level of DTDs or only entities ?]
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 human
intervention, as is the case with the XML exchange model [Ed Note: we need exact name here] developed
by the British Accounting Software Developers Association (BASDA).
[Ed. Note - Do we believe that XML requires human intervention?]
[Ed. Note - One member has proposed replacing "human intervention" with "flexible XML transactions
that can include human operators as well". Do we accept this change in concept?]
[Ed. Note - One member has indicated "Yes, sooner or later in a supply chain, there is the need for human
intervention and that it is very difficult to have fully automated processes in environements that are very
heterogeneous such as ports where many parties at different level of automatio have to
interact.intervention?" Another member has indicated " Obviously not! Only that XML transactions are
easier to utilize in a human interface, as well as being capable of machine interfacing only.]
[Ed. Note - One member has recommended removing the reference to BASDA because "- it does not
make sense to cite it, as this opens a whole huge can of worms of other less desirable stuff that BASDA is
attempting to push." However, another member has stated the intent of the BASDA reference was that he
was "trying to expand the tradtional EDI model to include the BASDA model. It assumes that a human
will review an order and supply edits and missing data before it is accepted]
2.2.2 Human to Application and Application to Human
? An ebXML compliant application must be able to generate XML encoded business documents that
may be displayed using the appropriate U.N. Layout Key [Ed note- do we need standards reference or
exact name?] when a layout key corresponding to the business purpose of the document exists.
[Ed. Note - On member has stated "I definitely disagree with this! Firstly UNICODE is the rendering
system for XML, and also this is DEFINITELY out of scope for our machine-to-machine interfacing focus.
Is there agreement with the requirement as written?]
? An ebXML compliant application (or environment, such as a web site) must enable data entry of
business documents using the appropriate U.N. Layout Key corresponding the business purpose of the
document. The data entry shall result in an XML encoded document representing the business
information.
[Ed. Note - Do we accept the requirement to use the U.N. Layout Key? One member has written "As a
submitor for such a proposal, I would recommend that one deliverable of the ebXML initiative is a NEW
UN recommendation in the line of the UN layout key but that is adapted to internet and XML. Key?"
Another member has indicated " Once again - this is a major NOT item. We could note the applicability of
the new XHTML recommendation, plus UNICODE as an advisement for future versions of ebXML to
encompass." Yet another member has stated "I think this is an implied part of the ToR]
2.2.3 Registry and Repository
A repository is required for storage and registration of ebXML related components.
[Ed. Note - A member has stated " Storage is useless if you can't retrieve anything! Lets explicitly state
that the repository must support process and topic related retrievals, as well as machine retrievals via an
API. Do we state this level of granularity at this point, move it to the detailed requirements in section 4, or
disregard?]
[Ed. Note - Do we need to move any detailed requirements from section 4 to here?]
2.2.4 Common Network Layer
[Ed. Note - A member has identified a need to articulate common network layer requirements as a
functional requirement. It is currently in non-functional as a bullet point. Is this satisfactory? One
member believes so.]
2.3 Non-Functional Requirements
2.3.1 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 Business Process - Both entities involved in the exchange of data must be engaged in the
same business process.
[Ed. Note - A member has stated: " This does not work. Lots of interchanges are pass-throughs to partners
who you deliberately want to handle some unrelated business process. Better is to state that "related
business process". Do we agree with this assessment? If so, what is the impact on this requirement?]
? Common Semantics - Meaning, as distinct from words or presentation.
[Ed. Note - Do we set the requirement to adopt an existing set of EDI semantics (UN/EDIFACT, X12,
other), an existing set of XML semantics (RosettaNet, CommerceOne, other), or develop a new set of core,
cross-industry semantics, or simply state the requirement for common semantics? One member has
indicated develop a new set of core, cross-industry semantics " gets my vote, not the others! We want lots
of other semantics to be able to utilize our aligning mechanisms." Another has written "It is my view that to
adopt UN/EDIFACT, X12 semantics is important as some of their semantics has legal and regulator value
at the international level such as customs requirements, proof requirements data and so on. It is my view
that the ebXMl requirement team takes note of the international and governmental requirements into
account as commerce happens in a legal and regulatory framework and the importance of the impact of this
legal framework was shown in the WTO Seattle conference. There are still issues that will be discussed at
WTO which will impact, sooner or later electronic business. Build on the work done by national and
international bodies can only speed up the implementation of our efforts." There appears to be significant
disagreement on this requirement and a need for developing consensus on the semantics approach of
ebXML]
? Common Language - Common vocabulary, with a one to one correspondence between words and
meaning.
[Ed. Note - Shall we sacrifice this requirement in order to meet internationalization requirements. One
member has written " NO! Common vocabulary based on a matrix where like terms and additional
translations can be cross-referenced." Another has written "From the UN point of view it is important that
we speak the same language in all languages. We solved the issue by using the concept of Source language
and target language. All work can be done in the source language e.g. english and translating into target
langauge depending on the langauge used in the country."]
? Common Character Encoding [NOTE - This could be achieved by specifying that only UNICODE (or
ASCII, or EBCDIC) be used.]
[Ed. Note - One member has written "XML uses UNICODE - no further discussion necessary. Does the
group agree with this position, and if so, do we remove this requirement, articulate a new UNICODE
requirement, or take some other action?]
? Common Presentation - Common set of XML attributes and common usage of those attributes,
common approach to document structure.
[Ed. Note - A member disagrees with this requirement stating "Again-this is what XHTML, JavaScript,
HTML, and DHTML bring us already. Do we consider this a valid requirement, or is it duplicative of the
aformentioned "standards". If duplicative, does that mean we disregard articulating the requirement for
ebXML?]
? Common Security Implementations
? Common Data Transfer Protocol - [NOTE - For example, could be achieved by always using SMTP,
or always using HTTP post and fetch.]
? Common Network Layer - [NOTE - For example, TCP/IP instead of OSI or SNA.]
[NOTE - In general, interoperability will assure platform independence.]
2.3.2 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.
[Ed Note - a member has asked "Should we add a requirement such as: minimize cost of creation,
management and use of documents?"]
2.3.3 Maximize Internationalization
Enable ebXML to be used in a user's native spoken language.
[Ed. Note - Support all languages, or a limited set of common languages? If a limited set, which ones?]
[Ed. Note - There may be other requirements beyond just multi-lingual support. 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.]
[Ed. Note - A member is in significant disagreement with this requirement - to wit " Sigh, Lets get this
right please. English is the preferred language for specifying ebXML mechanisms. All ebXML
mechanisms will support language neutral taxonomy representations that provide built-in multi-lingual
implementations. This particularly applies to repositories, where individual countries and industries may
establish equivalent translations for local use."]
2.3.4 Maximize Interoperability with existing EDI and XML Implementations
ebXML compliant applications should allow data exchange with existing EDI and XML/EDI schemes
while minimizing conversion required for exchange. This interoperability includes such aspects as
correspondence with existing EDI data element names and usages, segment layouts, transaction set or
message structure, and code lists.
[Ed. Note - This requirements potentially conflicts with maximum interoperability between ebXML
compliant applications (assuming a single ebXML "standard" is proposed to achieve that).]
[Ed. Note - A member has articulated the applicability of the SIMAC vision statement on this paragraph.
Does it apply, and if so, how does that change the requirement?]
[Ed. Note - A member has indicated the last sentence is a new test. Is it? If so, do we accept it? If we
accept it, what is the impact on other requirements?]
[Ed. Note - this paragraph as written does not agree with what I believe is already recorded as group
consensus.]
2.3.5 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.
[Ed Note - do we make reference to Recommendation 14 at this point?]
? 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-repuditation of Origin - The sender can not deny having sent the message.
? Non-repuditation of Receipt - The reciever can not deny having received the message.
? Reliable Business Classification Registry mechanism.
[Ed. Note - A member has stated that the repository must also verify who someone is, have a means to
support Dun and Bradstreet, and many other classification schemes, such as ISP themselves classifying a
business user. In fact we want to mandate the use of a classification scheme, and provide a flexible system
for any classification system." Do we agree with this requirement?]
2.3.6 Archiving and Legal
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, ebXML should support archiving of up to 30 years.
[Ed. Note - TBD, consensus needed on this issue beyond specific time period. One member has stated
time periods vary based on regulatory requirements. Another member has stated " I'd hate to put ourselves
legally on the hook for this! What I'd rather say is that `ebXML should contain reasonable and simple
mechanisms to allow third parties to create formal mechanisms that can support strong attestation of
ebXML content at a future date. Time period is just not possible - all we can do is state the aim of
achieving 30 years - advances in computer cryptology and other methods can invalidate this stuff
overnight!"].
3 Detail Requirements for an ebXML Compliant Application
Environment
[Ed. Note - this section was submitted by another working group. We may want to integrate the elements
contained in this section with Section 4, or otherwise determine how to best present these requirements.]
3.1 Registry and Repository
These are listed in terms of a business entity that might use the repository and registry.
[Ed Note - A member has stated "We probably want to move most of this up to section 2 as high level
requirements". A decision will be made after we meet with R&R]
3.1.1 Standards Development Workflow
3.1.1.1 Functional Requirements
? The business would like to support legacy information, including historical EDI directories ( X12,
UN/EDIFACT, etc. )
? The business would like to be able to store a legacy data model (e.g., IDEF-1X) and retrieve it back out
as a UML class diagram allowing them to further enhance the information within an object oriented
paradigm.
[Ed. Note - A member has indicated " This is clearly way off base! Better is to state that "The business
should be able to store a legacy data model as closely as possible using the hierarchical mechanisms that
XML provides. Conversion to newer formats should be facilitated but not guaranteed. We need to come to
agreement on validating or removing this requirement]
? The business would like to be able to store 100% of a UML model (OCL, use cases, state diagrams,
interaction diagrams, etc.) and retrieve it back out in its entirety.
[Ed. Note - A member has taken exception to this requirement. Specifically - " NO! NO! Please we are
picking tools here - NEVER pick tools as the business functional need!!! I'd also like to support STEP,
UDEF, Yourdan, Oracle Designer 2000, et al. NO! If people want to take an ebXML repository and link
it to their favorite flavour-of-the-month CASE syntax then XML allows them to do that. What we
REALLY want here is a SIMPLE neutral representation in the repository that captures the business
semantic content - both of legacy EDI and new XML business elements. " We need to validate consensus
on this requirement]
The business would like to be able to interactively map internal application semantics to horizontal and
vertical industry semantics (semantic equivalent mappings).
? The business would like to know in what context data is being used in the business process.
? The business would like to avoid reinventing the wheel, by reusing parts within the repository to
construct new file specifications.
? The business would like the ability to request a change or enhancement to an artifact within the
repository as a result of implementation issues.
? The business would like the ability to search for an item in the repository based, either an exactly
match or similar (fuzzy) capabilities.
? The business would like assign work items to others.
? The business would like to submit proposals for work items into the repository in any electronic format
possible.
[Ed Note - A member has indicated "These look like vendor specific features (wish list) rather than core
items that are must-have for simple ebXML machine-to-machine processing"]
? The business would like to know all the different specifications a particular data element is used in.
? The business would like to know all the vertical domains that a particular artifact (UML classes, XML
declarations) is used in.
? The business would like to be able to differentiate work in progress to that which is an actual standard.
[Ed Note - A member has stated " Ooops! Impossible! Can we spend next ten years arguing over what is a
standard? NO! Better is simply to know WHO is the owner of the particular item. So owner could be
ASC-X12, or Wal-Mart, or SEARS. This tells me exactly what I want to know in my business context." I
am not sure this comment is entirely relevent to the requirement. We need to discuss this. ]
3.1.1.2 Non-functional Requirements
? The business would like to utilize existing software and standards that are already in place. (reuse-buy-
build principle)
? The business would like to be ensured that no one changes the information in the repository that is not
authorized to do so.
? The business would like to be ensured that no one sees information in the repository that is not
authorized to see.
? The business would prefer names of items that are predictable, based on a formal scheme.
[Ed. Note - We need to validate this requirement given a members comment that " OK -this is absolutely a
non-starter again! We've spent the last two years deciding we cannot do this. Individual industry groups
will always make their own conventions. The only viable approach is to link a generic taxonomy (like
Barcodes) to a raft of like name items, and language usage."]
? The business would prefer version identifiers that are predictable, based on a formal scheme.
3.1.2 Application level Usage
3.1.2.1 Functional Requirements
? The business would like to have dynamic mapping tools that automatically retrieve the most current
file specification from a repository.
? The business would like to immediately retrieve a file specification to understand how to correctly
parse a file.
? The business would like to immediately retrieve a file specification to understand how to write out a
conformant file.
? The business would like to know in what context data is being used in the business process.
? The business would like to discover which trading partners are capable of engaging into a given
electronic business transaction.
? The business would like to know which trading partners provide certain products and services.
? The business would like to know what networking schemes must be used to physically communicate
with a trading partner.
? The business would like to publish their e-business capabilities / profiles within the registry to
facilitate discovery by intelligent information agents.
[Ed. Note - with respect to the last three bullets, a member has stated " Ooops - this is human-machine stuff
again, not machine-machine. Also this is already being covered by XML-DSML - see
http://www.dsml.org. Therefore I would suggest that ebXML take an action note that as far as possible
ebXML should be compatible with existing XML syntax recommendations that support this functional
need." Do we agree with this assessment? If so, what do we tell the submitting group?]
3.1.2.2 Non-functional Requirements
? The business would like a repository that is available on the Internet on a 24x7 basis
? The business would like repository performance levels that support real-time interaction with business
applications
[Ed. Note = A member has stated " Bit silly stating this - again these are vendor issues - not ones we need
to fuss with. BTW - perfectly possible to cache locally long standing definitions to remove the need for
24x7...and also provide fault tolerance. we could go on!" Is there agreement with this member's
statement?]
3.2 Transport and Routing
? There must be mechanisms to insure that a message is delivered exactly once.
[Ed. Note - A member has stated " More hog-wash! This is application specific stuff - some systems
deliberately deliver stuff more than once as a means of fault tolerance.. Better is to state (as was already
done earlier) that you can authenticate and verify delivery." Is there agreement with this statement, or do
we retain the requirement?]
? Various delivery modes must be supported, such as: routing of messages to single or multiple
destination, publish & subscribe (content and subject based), broadcast messages, streaming
? Multiple transport protocols must be supported.
[Ed. Note - A member has stated " NO! The ebXML delivery is transport layer neutral, just as XML itself
is." Is this technically correct? Do we agree we do not need to articulate this requirement?]
? Audit trails and traceability/trackability of transactions/documents must be supported.
[Ed. Note - A member has stated " Hello! This is application layer nonsense again - this may be a "we
recommend that" but if users don't have a business need they should be able to ignore it." Do we agree
with this assessment?]
? Quality of service - The following capabilities must be supported:
? Ability to specify that Processes/transactions complete within required time
? Non-transaction vs. transaction, exactly once behavior
? Level of service negotiation
? Service availability checking
? Transaction Status Inquiry
? Session based & long term transactions
[Ed. Note - A member has stated "Come on - please! How can we be delivery neutral and specify all this
stuff? Again - this is a recommendation that users should select a transport layer that supports the level of
delivery they need. We will need a batch process tracking mechanism (like punch-out but PLEASE do
NOT base this on proprietary `cookies' like cXML does for user-to-machine stuff!) but JMS, JINI, EJB,
eSpeak, BizTalk, DNA, SNA, et al, all do this differently" Do we agree with this assessment, and if so,
how do we state the requirement?]
? Restart and recovery - backup/rollback of business transactions must be supported
? Workflow of business documents
[Ed. Note - A member has stated " Both of these are VERY clearly out of scope for version 1.0 - machine-
machine processing - this is all human process stuff, or vendor specific functionality that's dependant on
the delivery system once again." Do we agree with this assessment? If so, how are we going to articulate
follow-on requirements?]
[Ed. Note - We may wish to insert all or part of the Draft ebXML Transport Definitions and Draft ebXML
Transport Requirements here.]
4 ebXML Guideline Requirements
This section addresses the requirements of those who will be implementing the guidelines by developing
compliant software applications. It contains more detailed requirements which are intended to enable the
requirements in section 2 and 3 to be satisfied.
4.1 General
? Define an XML-based schema for Electronic Commerce/Electronic Business
messages/transactions/documents.
? Specifically specify an ebXML "superset" business process model.
[Ed. Note - A member has stated " NO! We're not in this business - this will take years to develop! Do we
agree with this assessment and remove this requirement?]
? Provide a general specification for development of documents, not just a specific transaction set (i.e.,
not just Purchase Order, as was done by OBI spec)..
? Provide support for XML metadata, such as the ebXML version/release and information corresponding
to the EDI interchange headers.
? Define an XML syntax schema specification using DTD or XML-Schema for EB XML documents
[Ed. Note - A member believes this requirement supercedes the first bullet in this list. Does it?]
? Single Approach - Wherever possible, the ebXML guidelines shall specify a single approach.
? Cross industry applicability - The ebXML guidelines shall be applicable across a variety of industries.
? Vertical industry applicability - The ebXML guidelines shall also be applicable with an individual
industry segment.
? 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.
? The initial ebXML guidelines must be completed by mid 2000.
? The final ebXML guidelines must be completed by the mid 2001.
? The ebXML guidelines should support current business models and practices as well as new ones
developed through UML modeling. Implementing ebXML should not require changes to existing
business models or practices.
? Only standards and recommendations that have been approved by the appropriate bodies shall be used
in the ebXML guidelines.
[Ed. Note - A member has stated " What? This is handcuffing ourselves! We are a standards body!! I
think what is meant here is : As much as possible ebXML should utilize existing standards and
recommendations. Where new mechanisms are defined these will be accompanied by specific justification.
Fore instance - Repositories - we definitely need to break new ground, and also in enveloping and so on.
Another point here is that we should work with appropriate external organizations to get agreement on
syntax definitions where appropriate, or simply issue recommendations on extensions to their syntax if we
are met with obduracy and procrastination (that never happens right!?)! " What is the right approach? Do
we differentiate between approved W3C Technical Specifications and developing business standards? If
so, what are the rules for each?]
4.2 Technical Architecture
? The ebXML guidelines must provide a mechanism for full specification of the document semantics.
However, this implementing feature must be optional since many trading relationships will not require
this level of specification.
[Ed. Note - At least one member feels this requirement is unclear as written]
4.3 Core Components
? Core components shall be syntax independent, i.e., not specifically aligned with any existing syntax
based semantics such as ANSI X12 or UN/EDIFACT.
? Core components shall be defined to insure separation of common "fundamental" versus "extra"
specific
[Ed. Note - A member has stated " Better is to have "Basic interchanges" and "Rich Interchanges", or
Level 1, Level 2 and Level 3. So I can say my product supports ebXML Level 1 compliance, etc." Do we
accept this change?]
? Definition of the core components shall respect ISO 11179 rules
[Ed. Note - do we accept this requirement? What is the impact of limiting ebXML to ISO 11179 rules?]
? ebXML semantics should incorporate all that is currently defined in X12 and EDIFACT.
[Ed. Note - not sure how this agrees with work group consensus. Further, a member has stated " NO! NO!
I think what is meant here is "should enable as much compatibility with legacy EDI such as X12,
EDIFACT, HL7 and others, as possible". This is a major issue that we must fully discuss and reach
consensus on. Given my sense of current disagreement on this issue, we may also need to take this issue
forward for resolution]
]
? Consistency shall be required in all noun<->verb, verb<->noun utilization across all grammars
?
? [Ed. Note - A member has stated " Again - we only WISH! This simply is too much utopia! Level 1
ebXML probably does not include ANY <verb> - <noun> stuff - as it is a lightweight implementation.
We should instead state that "a <VERB> - <NOUN> directive mechanism will be part of the scope,
but will not be a critical need for ebXML. Such mechanisms may be deferred until later releases of
ebXML particularly if developing same will clearly halt the ability to meet timelines and deliverables
of key aspects of ebXML functionality". Do we agree with this assessment? If so, do we limit our
requirements to near term achievable?].
? Use of synonyms (eg., "new" and "create") shall be avoided
[Ed. Note - A member has stated " I think what is meant here is that ebXML should use a single consistent
set of terminology. An example of this can be seen from: http://www.bizcodes.org and the eDTD schema
draft, where the use of attributes within the schema is VERY consistent - unlike existing W3C DTD's that
use "#CDATA" and CDATA and so forth - which is very confusing!" Do we accept this position? If so,
do we incorporate specific solutions in our requirements?].
4.4 Transport/Routing and Packaging
? The guidelines shall specificy gow [Ed Note - what is gow?] to envelope business documents in regard
to:
? Related messages in a collection
? Physical and/or logical addressing of destination for messages
? The guidelines shall specify application level and not transport level exchange
? The guidelines shall specify wire format mapping
[Ed. Note - This requirement as written is unclear.]
[Ed. Note - A member believes this requirement is out of scope in that it is not machine-to-machine. Do
we agree with this assessment? If so, do we remove this requirement? Do we change scope?]
? Transaction Boundary: 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.
[Ed. Note - A member has written " Wow! OK - this stuff is definitely a separate effort - and I suspect it
will fail the litmus-test of transport layer and protocol independence... We should also look at ICE,
eSpeak, WFMG, as it seems those middleware guys are likely to be building this.." Do we agree with
this assessment? If so, do we remove this requirement or modify it?]
4.5 Legal
[Ed. Note - A member has articulated "In X12/EDIFACT, the version/release identifier references
published standards, and the semantic meaning of the conveyed information is defined by those standards.
In XML, the version/release identifier may reference a 'point in time' semantic definition (e.g., a DTD) that
is not published and might not be capable of reconstruction at a later date.
[Ed. Note - A member has stated " according to this, when you create a version, those physical files are
retained. Therefore, the statement here makes no sense. Also - if we insist on external DTD / schema,
NOT embedded ones - then versioning and retention are easily managed." Do we agree with this
position?]
Also, in an X12/EDIFACT based system, the semantic interpretation of the transmitted data is pre-defined
by the referenced standard (as for example by a built-in EDI translator table). In an XML-based system, the
semantic interpretation of the transmitted data is not pre-defined, but rather is based upon the behind-the-
scene (and probably unsigned) transmission of the metadata."]
[Ed. Note - Do we convert this note to text? If so, do we need to articulate requirements that address this
Note? If so, what are those requirements? Do they include business/legal constraints on the XML based
system with respect to metadata? Additionally, a member has stated " Again - good lateral thinking - but
ignoring the obvious! The repository solves this - because it is that piece that is carrying the semantic
linkage - currently in the IC and IG's in EDI." Is this position correct? If so, how does it impact on our
thinking?]
[Ed. Note - A member has articulated "In X12/EDIFACT, the facilities for signing/encrypting documents
are quite extensive (e.g., signature over signature), whereas existing work with XML/EDI has only
supported communication layer signatures/encryption." Another member has stated " Hello! Add
<signature> blocks to your messaging, and you can achieve all of these mechanisms. Therefore - maybe
you just want to state that ebXML transactions will contain <signature> block(s).]
[Ed. Note - Do we convert this note to text? If so, do we need to articulate requirements that address this
Note? If so, what are those requirements? Do they include the following: business/legal security/privacy
requirements? ]
[Ed. Note -A member has articulated "In X12/EDIFACT, detailed metadata is associated with every
transmitted data field. XML does not require that transmitted data be associated with detailed metadata."
Conversely, another member has stated " Again - by applying linkage to the schema / DTD and the
repository this whole issue is solved. Therefore - stating that "XML syntax should carry semantic link to
the repository definition", very neatly solves this and points into the repository work." Do we favor either
of these positions?]
[Ed. Note - Do we convert this note to text? If so, do we need to articulate requirements that address this
Note? If so, what are those requirements? Do they include the following: What are the business/legal
metadata requirements? Must all transmitted data be defined by (some well-defined minimal set
of)metadata? Are there 'completeness' requirements for documents? Are there value range requirements,
Etc? ]
4.6 Registry and Repository
A repository of ebXML products should be developed. If ebXML is to exist beyond its initial 18 month
timeframe, then ebXML should maintain this repository. If not, then ebXML must determine if the
repository should transition to CEFACT, OASIS, XML.ORG, BizTalk, or some other existing XML
business standards repository.
? The caretaker of the ebXML repository must establish open management processes
? The ebXML repository must have open access
? The ebXML repository must have interfaces with other existing and planned XML business standards
repositories
? The ebXML repository must accommodate:
? Versioning
? Metadata Registry
? Model interchange (UML - XML schemas)
? tool to tool
? repository to repository
? tool to repository
? repository to tool
? Model integration (e.g., how to create an XML schema from a UML diagram and vice-versa without
loss or gain), A web site for ready access to glossaries shall be created and maintained.
? The ebXML repository should include
? 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 (TMWG Unified
Modeling Methodology document Annex 1 is a start)
? A glossary of terms specific to each business process to be modeled shall be created and
maintained.
? A glossary of XML tags shall be created and maintained.
? Glossary
? Archives of previous ebXML standards
[Ed. Note - A group member has articulated a need to be able to reconstruct the exact information content
of a message received 20-30 years ago and the need to have standards versioned and historically
understandable.]
4.7 Business Process Methodology
? A high-level business process methodology shall be provided in terms of XML, i.e., DTD.
? A methodology with which to specify "vertical" business processes according to a uniform "template"
shall be selected (i.e., ebXML "superset") so they can be compared.
? The ebXML "superset" business process meta-model shall be explicitly specified, not implied by
instantiations or derivations.
? Every effort shall be made to incorporate cross-industry methodologies for specifying business
processes, e.g., OAG, RosettaNet, HL7, into the ebXML "superset."
? 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 (TMWG Unified
Modeling Methodology document Annex 1 is a start)
? A glossary of terms specific to each business process to be modeled shall be created and maintained.
? A glossary of XML tags shall be created and maintained.
? A web site for ready access to glossaries shall be created and maintained.
4.8 Interoperability
[Ed. Note - It is unclear if we have adequately addressed interoperability or if interoperability should be
listed as a separate requirement. If we are to keep a separate section, then what are the requirements? The
following narrative from the previous document is included in this note for purpose of discussion ]
"The major non-functional requirement stated in the ebXML Terms of Reference (ToR) is 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.
[Ed. Note - A member has stated "Common Semantics and Common Language" are duplicative from
previous sections. Do we agree they are duplicative? Is there a valid reason to duplicate given the format
of the document?]
*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. 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.
* Some business advice on this topic beyond 'must support interoperability' is needed (E.g., the scope of
interoperability; upon which party or parties does responsibility lie for achieving interoperability;
acceptability of non-XML based solutions)
*Scope might include some existing XML/EDI applications, such as a RosettaNet application; some
existing XML capable non-EDI applications, such as ORACLE-based application products. ebXML
conformance could be defined such that both a RosettaNet application and an X12 Technical Report based
application were implicitly ebXML conformant, or ebXML could be defined such that neither was
conformant, but each could be transformed by some XML-based process to be ebXML conformant and so
to be interoperable.
*Responsibility might be defined as the responsibility of the ebXML non-conformant party (my
recommendation) to provide an XML-based process to convert between a non-conformant XML
application format and an ebXML conformant XML application format, or responsibility might simply be
to provide sufficient metadata information to support an algorithmic conversion.
Non-XML based systems (e.g., a hard-coded application specific translator) might or might not (my
recommendation) be tolerated in an ebXML conformant interoperable system.
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? "]
[Ed. Note - A member believes most of this is included above under section 2. and thinks that if there is
anything in 4.8 that isn't addressed adequately in section 2, we should move it up there. Do we agree with
this position?]
5 ebXML Organizational and Procedural Requirements
? The process by which the ebXML organization is managed must be open and consensus driven
? The process by which ebXML products are developed must be open and consensus driven.
? The process by which the ebXML guidelines are approved must be open and consensus driven.
? The process for developing ebXML guidelines and standards must be timely and responsive to
business needs
[Ed. Note - We need to be more specific here]
? The standards process must have controls to prevent creation of equivalent components.
? There must be a single body that is responsible for long term maintenance of the ebXML guidelines.
? The process for long term maintenance of the ebXML guidelines must be specified.
? ebXML funding methodology must be determined
? Requirements for short and long term ebXML relationships with CEFACT, W3C, ANSI, ISO and
other standards bodies must be defined
? Requirements for short and long term ebXML relationships with OASIS, BizTalk, CommerceOne,
RosettaNet, and other XML business standards bodies must be defined
6 Requirements for ebXML Technical Coordination & Support
Single point of contact, etc.
7 Requirements for ebXML Marketing, Awareness & Education
The real success for ebXML will be in its adoption by the business community. To help facilitate that
adoption, the ebXML team must ensure the business community is aware of
? Training, Publicity, Others
? Marketing /Promotion
? Recruit (ebXML must identify and recruit the relevant bodies / companies/ organizations -e.g., SWIFT,
Rational-)
? Awareness/Education
? Promote, evangelize, educate
[Ed. Note - Is this appropriate for this type of document? At least one member has stated they think it is
outside the scope of this document]
8 ebXML Work Group Deliverables
This section identifies required ebXML Work Group deliverables to include a listing of specific guidelines
to be produced, with a brief description of each.
[Ed. Note - Are we comfortable in trying to define deliverables in a requirements document, or should we
simply state deliverables will be determined by the individual work groups to meet the requirements
identified in this document?]
8.1 Initial Deliverables
These items are to be completed by mid 2000.
To be completed
8.2 Final Deliverables
These items are to be completed by mid 2001.
To be completed
9 Add to Glossary Terms
Functional Requirements - Functional Requirements are typically phrased with subject/predicate
constructions, or noun/verb. "The system prints invoices." From a mathematical point of view, a "function"
takes an input(s) and yields an output(s). "Functional" refers to the set of functions the system it to offer.
Alternate: A system/software requirement that specifies a function that a system/software system or
system/software component must be capable of performing. These are software requirements that define
behavior of the system, that is, the fundamental process or transformation that software and hardware
components of the system perform on inputs to produce outputs.
Non-functional Requirements - Non-functional requirements may be found in adverbs or modifying
clauses, such as "The system prints invoices *quickly*" or "The system prints invoices *with
confidentiality*". "non-functional" refers to the manner in which system functions are performed.
Alternate: In software system engineering, a software requirement that describes not what the software will
do, but how the software will do it, for example, software performance requirements, software external
interface requirements, software design constraints, and software quality attributes. Nonfunctional
requirements are difficult to test; therefore, they are usually evaluated subjectively.
ebXML Requirements Specification Version.htm
ebXML Requirements Specification Version.doc
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC