OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-requirements message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: 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]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC