Re:Work Plan Change, Agenda for 1/7, and Issues List

["Mark CRAWFORD"<mcrawfor@mail.lmi.org>]

XML Requirements - 

ebXML Requirements Specification 

1 Introduction 

1.1 The ebXML Initiative 

Background on this initiative 

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 standardised. The goal is to provide 
an open technical framework to enable XML to be utilised in a 
consistent and uniform manner for the exchange of Electronic 
Business 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 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 stovepiped XML DTDs and schemas. 

1.2 Document Purpose and Scope 

1.2.1 Purpose

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.2.2 Scope of ebXML initiative

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 organisation of the group;

* Target time scales and milestones for its deliverables; and

* A proposal for membership from other relevant groups and 
organisations.


1.3 References and Related Efforts To other documents 

1.4 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) -

1.5 General XML Requirements and impetus for use

XML is the de facto, standard, serialized vocabulary of the 
Internet, EC, EB and 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.

Need to address the basic reasons why people want to use XML? The 
Business / Customer users want XML because... - Moves them to 100% 
paper-less operation. - Provides one documents format for both 
browser and computer application - Moves them to cheaper web/ 
Internet solution. - User oriented solution, does not require a 
programmer. - It provides a migration path from EDI to XML EDI to 
OO-xml/edi - Summary: Its fast, cheap, web based and widely 
accepted But, Business users don't want... - To scrap existing EDI 
investment and operation - To waste time waiting for the perfect 
XML solution that would require much time, many meetings, much 
consensus, much re-investment and re-education - To move to a new, 
single, complex e-solution which requires too much rethinking of 
business models too soon. What if it doesn't end up being the 
"standard". - Divergent XML DTD developments (similar to EDI 
divergence) The Technical / Functional users want XML because... - 
Now able to build and send self-explanatory document definitions 
along with the document - Now able to expand the scope of document 
constructs to support object technology and UML based document 
design. - Now able to achieve truly open, web based e-business 
solutions with a global reach.

XML shall be cross-industry usable

In addition to interoperability, I believe there are two other 
major non-functional requirements. The first is the reason we are 
even considering XML over traditional EDI. That requirement is 
minimizing cost of application-to-application exchanges. The 
second is internationalization, i.e., the ebXML approach should 
meet the needs of all nationalities that use it. All other 
requirements, including any dealing with repositories, modeling, 
security, etc., are secondary to these. The functional 
requirements require little elaboration. However, we must 
decompose the non-functional requirements and further clarify 
their meaning. Note that in most cases, as we maximize 
interoperability we may also minimize cost. Therefore, these 
requirements are synergistic. 

1.6 General ebXML Standards Requirements

Determine how ebXML products can best coalesce the structure and 
content components of divergent XML standards into a single 
useable XML business standard.

Common resources currently engaged in short-term solutions shall 
be marshaled to reach a common long-term solution goal 

Determine 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.

A global open /interoperable standard for specifying a document 
markup language based on plain-text tags.

An XML-based business process integration shall be accomplished by 
means of a cross-industry global standard 

ebXML global standards should be common to 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.

ebXML standards should facilitate paper-less, electronic web 
/internet exchange of business information at the reasonable cost 
of internet service.
 
This XML exchange of information should help 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 parner system 

- 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. 

- ebXML standards if defined correctly should be SIMPLE, EASY and 
UBIQUITOUS 

- ebXML standards have to be defined and adopted by mid-year 2000. 
Any delay or debate or search of a PERFECT process for its 
definition beyond mid-year 2000 will only help boost fragmented 
XML efforts in variety of industry sectors and a true opportunity 
for a global standards will be LOST forever.

We heard a lot of comments about this being useful for the SMEs, 
however, I think that unless its also useful for the BEs (Big 
Enterprises) or LEs (Large Enterprises) it won't go very far. BEs 
have to deal with other BEs and SMEs simultaneously. Since the 
majority of BEs are already heavy EDI (X12 or EDIFACT) users, they 
have to be able to operate in that mode while they are trying to 
branch out and reach SMEs that may come up fresh using XML. 

I also think that we must try to avoid one of the problems that 
occurred in the early days of EDI. -- trading partner pairs and 
then industry groups can come up with their own set of standards 
for quick starts. It didn't take long to discover that no 
business, or industry group is an island, unto themselves. 
Incompatible trading partners started to bump into one another. We 
need to figure out a way to allow new things to be added quickly, 
but at the same time guard against the situation where we have two 
different ways of specifying the exact same thing.

The "Big Enterprises" are the critical ebXML players. - Their 
business management must be convinced that it will be good for 
them. - They are the same players who have an installed EDI base / 
investment to protect. - The simplest sell to these players will 
be to provide a migration path from EDI to XML. 

Technical users don't want... 

* To develop more than one type of XML solution regardless of 
variations of documents business use or purpose. (A migration 
path)

* To provide an interim solution to solve the business objectives 

Perceptions: - Any XML/EDI standards should be "complimentary" to 
any long-term, object-based XML standard and should not be seen as 
"competing". It's a matter of perception.

It appears that much "XML activity" to date has been a purely 
technical / functional "recasting" of business interchanges in 
"interactive form" for an industry specific consortium with 
minimal cross industry business perspective. The "technocrats" are 
still doing most of the work. - "The intelligence of XML is 
carried with the content and not in a software dependent 
solution." This is good and bad for standardization, Configuration 
Mgt. and reuse issues. XML documents and their definitions can be 
changed on the fly.  


1.7 Success of the ebXML initiative

Define the measure of success for this initiative


2. Requirements for an ebXML Compliant Application 

Functional Requirements of an ebXML application

A. 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

2.1 General 

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 uptodate. Each Version revision should continue to support 
past revisions. 

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. 


2.2 Application to Application 

This is the application to application area in the ToR. 

2.2.1 Functional Exchange documents, acknowledgements, etc. Much 
of this can be derived from the X12, EDIFACT, and ISO 9735 
standards. 
	
2.2.2 Non-functional Inter-operability, security, scalability, 
flexibility, minimize cost, etc. 

2.3 Human to Application 

* Display business documents (represented in XML) using the 
appropriate U.N. Layout Key when such a layout key exists - This 
covers application to human. * Enable data entry of business 
documents (represented in XML) using the appropriate U.N. Layout 
Key when such a layout key exists - This covers human to 
application. 
	2.3.1 Functional 
	2.3.2 Non-functional

2.4 Related Issues

2.4.1 Common Network Layer - For example, TCP/IP instead of OSI or 
SNA. 

2.4.2 Minimize Cost  

* Acquisition - Cost of purchasing ebXML compliant applications 

* Development - Cost to software vendors or large organizations of 
developing ebXML compliant applications.

2.4.3 Operation and Support - Monitoring, problem resolution, 
adding new trading partners, staff training, etc. Maximize 
Internationalization

3. ebXML Guideline Requirements 

This section will include more detailed requirements, which are 
intended to enable the requirements in section 2 to be satisfied. 
In particular, it will be based on the requirements relating 
directly to ebXML work group efforts. [Note: Technical 
Coordination and Support and Marketing Awareness and Education may 
not produce guidelines, so they are omitted here] 


3.1 General Characteristics of the guidelines, such as in public 
domain, freely accessible via web, etc. 

* Define how the ebXML standards development process will follow 
those of W3C? X12? CEFACT? ISO? Other? 

* 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. 


* Determine if the ebXML business standards should follow the 
structure of existing X12 transaction sets, EDIFACT Message 
models, BizTalk Schema, RosettaNet PIPs, Other existing standards. 

* ebXML standards DTD's limitations for controlled customization 
and extensibility should be avoided.

*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. 

3.2 Technical Architecture 

Technical Requirements Define an XML-based schema for Electronic 
Commerce/Electronic Business messages/transactions/documents. 
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 

3.2.1 Legal Requirements 

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. 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. From a 
business/legal viewpoint, what constraints need we place on the 
XML based system with respect to metadata? One possible solution 
to the metadata problem might be to include a hash of the metadata 
along with the reference to it, and place the responsibility of 
verifying the metadata hash and retaining a copy of it for legal 
disputes upon the concerned parties. 

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. From a business/legal viewpoint, what are 
the security/privacy requirements? The expedient thing to do would 
be to accept the communications level solution for now, but is it 
adequate for now? 

In X12/EDIFACT, detailed metadata is associated with every 
transmitted data field. XML does not require that transmitted data 
be associated with detailed metadata. 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? 


3.2.2 Interoperability Requirements (among disparate XML-capable 
systems)

The major non-functional requirement stated in the 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. 

*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?  


3.2.3 Lessons learned from Industry and Standards Organizations. 

We cannot expect the same (XML) documents to work the same way for 
all industries. Case in point: The Telecommunications Industry is 
spending much time in developing telecommunications "sales and 
service models" and related XML documents (modules). But, these 
are NOT readily usable by most other service industries (such as 
airline mechanics.) - X12 standards are an accumulation of 
"industry specific business cases (scenarios)" which have been 
normalized/ consolidated into "standard transactions". This then 
forced each industry to write its own conventions for defining how 
to extract their "industry transaction subset" out of the 
"standard X12 transaction superset". To date, there have no 
ubiquitous, cross industry transactions that are usable right out 
of the box. Can /should XML be expected to solve this problem? 

Determine ebXML design rules for XML DTD's and Schema's. 


3.3 Core Components 

Semantics and Message Architecture
Use existing semantics in some uniform way (especially reuse some 
"horizontal" semantics)

Normalized components shall be identified (Supply-chain management 
possible source)

Every effort shall be made to incorporate cross-industry 
methodologies for specifying business processes, e.g., OAG, 
RosettaNet, HL7, into the ebXML "superset." 

3.3.1 ebXML tag names 

Determine if ebXML should tags replicate, incorporate, identify, 
reference, or otherwise align with EDIFACT/X12/HL7 data 
element/code semantic names and syntactic requirements.

It think we should try to use one set of tags to cover both X12 
and EDIFACT semantics rather that one for X12 orientation and one 
for EDIFACT. We will need to distinguish content (e.g. code 
values), however, this should be specified higher up in the 
exchange or referenced somehow. 

Reuse/compose existing elements/components Extensions of existing 
messages (to cover new applications)

Identify core data ( horizontal semantics)

ebXML standards should support syntax independent message design 
guidelines which will harmonize EDI and future XML architectures 

Technical users don't want... - To use existing document and 
element semantics (tags and meaning) from EDI. - 

Semantic Foundation

Semantics equivalents between data elements

Transformation of semantics

Internationalization / Multi-lingualism

ebXML Semantics The ebXML semantics should at a minimum cover the 
semantics contained in X12 and EDIFACT. This is not to say that 
every X12 Transaction Set nor EDIFACT message be specified within 
ebXML -- only that one could if desired express the TS or message 
in ebXML. We may, however, have to be able to distinguish between 
X12 and EDIFACT semantics at the instance level. We may very well 
want to go beyond the semantic requirement of X12 and EDIFACT, 
however for our short term delivery we may want to use those as 
our baseline. 

Where possible, ebXML specification shall be based on X12 and 
UN/EDIFACT semantics and code lists. 

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

Document Component Use and Reuse Requirements - XML Documents can 
be Simple, Complex, Compound, Batch and Interactive. One size of 
XML solution /standard may not fit all. - EC/EB Users are Big 
Enterprises and Small/ Medium Enterprises. One size of XML may not 
fit all. I contend that there should not necessarily be one size 
of ebXML for all sizes of players. - Global Multi-lingual 
standards will be a hassle unless there is a "simple language 
transformation capability" at the "directory level". We should not 
be building semantically similar solutions in different languages. 

3.3.2 Internal/External Codes 

ebXML must be able to handle the internal and external codes used 
by both X12 and EDIFACT. The X12 dictionaries and the EDIFACT 
Directories should be the source for internal codes and identify 
the source of external code lists. Again we may want to go beyond 
X12, EDIFACT; however, we still have the potential compatibility 
issue. We want to make it easy to add/modify new codes/code 
sources, but we need rules so that it doesn't get out of hand. The 
EWG model works pretty well. 

Code Use We need to make certain that the codes and code lists 
usage in ebXML is the same as EDIFACT and X12. That is, we don't 
want a situation where a business application process must 
reconcile the differences between e.g. an EDIFACT Purchase Order 
feed and an ebXML Purchase Order feed. This does not mean the 
ebXML specifications should not go beyond X12 or EDIFACT.

3.3.3 Other existing data dictionaries

I see no reason why we cannot provide for both X12/XML and 
EDIFACT/XML as well as a SPEC 2000/XML and a STEP Product 
Data/XML. If we move the semantics directly from the existing EDI 
or Product Data standard to XML without reinventing new tags and 
taking years to come to a consensus on their meaning, then we are 
better able to migrate the "users" of those standards to the 
"ultimate ebXML standards". The more complexity we put into the 
initial XML solutions the longer it takes and the smaller the 
window of opportunity to gain wide spread use.

XML will not simplify "X12/ EDIFACT alignment". X12 EDI and 
EDIFACT are "functionally equivalent (not equal)" and cannot be 
cross ref. Matrixed without interpolation. 

3.4 Transport/Routing and Packaging 

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


3.5 Registry and Repository 


Determine if ebXML should create its own XML business standards 
repository or use XML.ORG, BizTalk, or other existing repository. 
- 

If ebXML creates an XML business standards repository, who will 
maintain it? Control access? Create interfaces with other existing 
and planned repositories?

Repository requirements -


* 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. 

* 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 
Modelling 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 - A look into the future There is a need to be able to 
reconstruct the exact information content of a message received 
20-30 years ago. It may be required for example in a legal court 
setting. Need to have standards versioned and historically 
understandable.


3.6 Business Process Methodology 


4.  Requirements for ebXML Technical Coordination & Support Single 
point of contact, etc.


5. Requirements for ebXML Marketing, Awareness & Education 

* 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 

6. ebXML Work Group Deliverables A listing of the specific 
guidelines to be produced, with brief description.

7. ebXML Organizational Requirements

Should XML standards development and management solutions to be 
implemented by OASIS, CEFACT, or ebXML? 

-The process for ebXML standards definition and approval should 
follow a FAST TRACK guideline without bunch of Committees, Task 
Group approvals issues that have invariably stalled this effort.

-Open Process You would want to have an open process in place 
whereby they can go to request addition/deletions/and 
Modifications to the semantic messages or code values. Suggest 
that it be under the UN. Also we do not want the process 
controlled by some interested group who could arbitrarily shut 
them off. Thus the UN process. Long haul Want to know that the 
process and standards will be there for a long time. Concerned 
that some group starts a process and since they really control it 
decide for business reasons to shut it down. Keeping the process 
under the UN umbrella is seen as the best way to guarantee the 
long haul. 50-100 years. 
-
Define the short and long term strategies of ebXML as an entity.

Define how ebXML management to be accomplished on both the short 
and long terms.

Define how ebXML operations are to be funded on both the short and 
long terms.

Define the long-term relationship between ebXML and CEFACT, W3C,  
ANSI, ISO. 
 
Define the long-term relationship between ebXML and OASIS, 
BizTalk, CommerceOne, RosettaNet, Other XML standards bodies. 

Define how we achieve success (see 1.7)


Non-functional Requirements of an ebXML application
* Technical Support

* Maintain the ebXML web site

* Certification 

* Test beds

* Developer Starter Kits








Removed Text

Tom Warner -

(I know this because I chaired the committee that developed the 1st two EDIFACT 
Messages and I drafted the X12 to EDIFACT Recasting Tool Kit. I also worked on 
the initial X12 / EDIFACT Alignment Subcommittee.) 

I believe that Industry Groups will continue to be the center of implementation 
activity for any XML standard. I see the industry organizations such as AIA, 
EIA, ATA, AIAG, SWIFT etc. as the best vehicle for obtaining acceptance and use 
within a minimal time period. They are best able to match the business solution 
to the technical capability. This should be exploited rather than be ignored. 

Kenji Itoh -

I researched ebXML Requirements based on two papers which I introduced at the 
meeting in San Jose; (1) Electronic Business XML Initiative - Terms of Reference 
(2) UN/CEFACT/TMWG/N104 Recommendation for ebXML Kick-off Meeting. These two 
papers may not be covered all of requirements completely, but as the starting 
point, I think they are very useful and supportive documents.

Donald Rudie
All, First of all let me say that we had a good kick-off meeting for the ebXML 
initiative. I also realize that we have a very important task of specifying the 
requirements for this initiative. I want to share some general thoughts with you 
before we get too deep in the details of the specific requirements. This will 
build on my statements at our first meeting. The topics discussed below are 
meant to be a starting point. Neither the topics identified nor the discussion 
is intended to be exhaustive. In addition, topic order does not indicate 
importance in my mind.
Hope that this does not sound too long and vague. This a first attempt at our 
overall scope. Interested in your reaction. 

Rawlins ebXML Requirements  -

This list generally follows the proposed outline. Where I see a significant 
issue or decision to be made, I highlight it with "ISSUE:". I see three major 
functional requirements and one non-functional requirement expressed in the 
Terms of Reference and discussions which clarified the ToR. The functional 
requirements are: 

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

NOTES: There may be other requirements here as well, any ideas? Note also that 
fulfilling this requirement may also tend to dictate a character encoding such 
as UNICODE that is capable of representing complex character sets. 


Mark Crawford -

Moving to a more personal perspective, my client base consists of various 
agencies within federal and state governments. Within that client base, 
mainframe legacy systems will continue for many years, EDI use will continue for 
many years, XML implementation will be as varied as the business process and 
organizational structures involved - both within and across business unit and 
agency boundaries. The agencies, either individually or collectively, can not 
afford to participate in every collaborative standards effort underway. As a 
result - unless ebXML or some other universally accepted XML business standards 
development and maintenance body is successfully established - their business 
requirements will not be addressed across the full range of developing XML 
business standards. This will lead to sub-optimizing XML use within the 
government through XML deployments that consist of a combination of assorted XML 
business standards and internally developed federal XML schema's and tags.

Paul Levine (team leader of the BPM project team) - 

The current list of business process methodology requirements follows:

XML Requirements Version 0_1.doc

Removed Text in Word.doc

To All,

    As promised in yesterdays message, I have taken the consolidated document of
requirements submissions I sent out yesterday and attempted to reorganize within
the bounds of the outline Mike had previously submitted (although there were
some instances where I have added an element or two to the outtline.)  (See XML
Requirements Version 0_1) .  Per a number of members requests, I have included
both plain text (with line breaks) and Word versions.  

Please understand this is a first cut - I am sure there are components that I
have put in the wrong section and ask you to point those out.  I have not yet
attempted to do any editorial changes.  I believe I have captured all relevent
comments, but to ensure that I didn't leave anything meaningful out, I am also
attaching another file that contains all deleted text (by author) that is not
included in the requirements document.

    

    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"