Re: Reminder - ebXML Requirements Conference Call this Frida

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

To All,

I have created a single .txt file that contains what I believe to be 
all requirements submissions and am forwarding that to all on the list 
in case they may have missed a submission.  By the same token, if I 
have missed someones submission, please bring it to my attention.  At 
this stage, the file is sorted by submitter.  My intent, baring 
unforseen workload tomorrow, is to transition the components of each 
submission into Mike's draft outline and to send that revised file to 
you by COB tomorrow so that you can review it for comparison to Mike's 
forthcoming issues list prior to Friday's call.

Mark


XML Requirements - 

Ravi Kacker -


- A global open /interoperable standard for specifying a document markup language based on plain-text tags. 
- ebXML standards should support syntax independent message design guidelines which will harmonize EDI and future XML architectures. 
ebXML standards DTD's limitations for controlled customization and extensibility should be avoided. 
- 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, instal 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. 
- 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. 
- 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. 
- 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. 

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. General Comment 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 rea!
ch 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. 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. ebXML tag names 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. 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 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. Archives - A look i!
nto 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. Hope that this does not sound too long and vague. This a first attempt at our overall scope. Interested in your reaction. Dr. Donald D. Rudie 


Mark Crawford -

- What do we, as business standards consensus building experts (as opposed to parochial X12/CEFACT/OASIS members) believe should be the solution for the ever-expanding universe of stovepiped XML DTDs and schemas? How do we go about making that solution a reality? 
- What are the short and long term strategies of ebXML as an entity? 
- Are we creating XML standards development and management solutions to be implemented by OASIS, CEFACT, or ebXML? 
- If we are developing solutions to be implemented by ebXML, how is ebXML management to be accomplished on both the short and long terms? Funded (same points of reference)? 
- Should an ebXML standards development process follow those of W3C? X12? CEFACT? ISO? Other? 
- What should be the long-term relationship between ebXML and CEFACT? W3C? ANSI? ISO? 
- What should be the long-term relationship between ebXML and OASIS? BizTalk? CommerceOne? RosettaNet? Other XML standards bodies? 
- What do we define as success? 
- How do we achieve it? 
- Should ebXML business standards follow the structure of existing X12 transaction sets? EDIFACT Message models? BizTalk Schema? RosettaNet PIPs? Other existing standards? 
- Should ebXML tags replicate, incorporate, identify, reference, or otherwise align with EDIFACT/X12/HL7 data element/code semantic names and syntactic requirements? 
- Should ebXML tags replicate, incorporate, identify, reference, or otherwise align with those of BizTalk, RosettaNet, XML.ORG, CommerceOne, or other XML business standard efforts? 
- How can ebXML products best coalesce the structure and content components of the above stated standards into a single useable XML business standard? 
- What are the right design rules for XML DTD's? Schema's? 
- What is 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? 
What is the impact of the current immaturity of various technical specifications on ebXML work in the short term? Long term? 
Should ebXML create its own XML business standards repository or use XML.ORG? BizTalk? Other? 
- If ebXML creates an XML business standards repository, who will maintain it? Control access? Create interfaces with other existing and planned repositories? 

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.

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.

1. Introduction

Electronic Business XML (ebXML) is an International Initiative established by UN/CEFACT and OASIS with a mandate to undertake a 15-18 month program of work. 

2. Purposes

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. 

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

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.

5. ebXML Requirements

5.1 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

b)  Semantics and Message Architecture
* Use existing semantics in some uniform way (especially reuse some "horizontal" semantics)
* Reuse / compose existing elements/components
* Extensions of existing messages (to cover new applications)
* Identify core data ( horizontal semantics)
c)  Semantic Foundation
* Semantics equivalents between data elements
* Transformation of semantics
* Internationalization / Multi-lingualism
d)  Registry and Repository
* 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)
5.2 Non-functional Requirements of an ebXML application
* Technical Support
- Maintain the ebXML web site
- Certification 
- Test beds
- Developer Starter Kits
* Glossary
5.3 Requirements of the ebXML Guidelines
5.4 Organisational Requirements
5.5 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

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

The current list of business process methodology requirements follows: 1. An XML-based business process integration shall be accomplished by means of a cross-industry global standard; 
2. XML shall be cross-industry usable; 
3. Normalized components shall be identified (Supply-chain management possible source); 
4. Common resources currently engaged in short-term solutions shall be marshaled to reach a common long-term solution goal; 
5. A high-level business process methodology shall be provided in terms of XML, i.e., DTD. 
6. 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. 
7. The ebXML "superset" business process meta-model shall be explicitly specified, not implied by instantiations or derivations. 
8. Every effort shall be made to incorporate cross-industry methodologies for specifying business processes, e.g., OAG, RosettaNet, HL7, into the ebXML "superset." 
9. 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) 
10. A glossary of terms specific to each business process to be modeled shall be created and maintained. 
11. A glossary of XML tags shall be created and maintained. 
12. A web site for ready access to glossaries shall be created and maintained. 

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: * Exchange business documents between applications (using XML) - This is the application to application area in the ToR. * 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. The major non-functional requirement stated in the ToR is Interoperability. 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. 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. * Co!
mmon 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. * Common Network Layer - For example, TCP/IP instead of OSI or SNA. 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. Maximize Internationalization ------------------------------------- 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? 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 th!
at is capable of representing complex character sets. 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. Security - Of message exchange. Composed of authentication of sender, message integrity, confidentiality, non-repudiation of receipt, non-repudiation of delivery. Requirements of ebXML Guidelines ========================== These address the requirements of those who will be implementing!
 the guidelines by developing compliant software applications. * 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. 

Tom Warner -

1. 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 s!
end 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. But, Technical users don't want... - To use existing document and element semantics (tags and meaning) from EDI. - 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 expressed in 1 above. 2. 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. 3. Perceptions: - Any XML/EDI standards should be "complimentary" to any long-term, ob!
ject-based XML standard and should not be seen as "competing". It's a matter of perception. - XML is the de facto, standard, serialized vocabulary of the Internet, EC, EB and ERP. Why? 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. - 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. - XML will not simplify "X12/ EDIFACT alignment". X12 EDI and EDIFACT are "functionally equivalent (not equal)" and canno!
t be cross ref. Matrixed without interpolation. (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.) 4. 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. 5. 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? 6. Final Opinion: - 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 reinventi!
ng 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. - 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. 

Bob Miller -

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? Interoperability Requirements (among disparate XML-capab!
le systems) * 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. 

Kit Lueder - 

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). Define an XML syntax schema specification using DTD or XML-Schema for EB XML documents. Where possible, ebXML specification shall be based on X12 and UN/EDIFACT semantics and code lists. Provide support for XML metadata, such as the ebXML version/release and information corresponding to the EDI interchange headers. 


Current Outline -

ebXML Requirements Specification 
1 Introduction 
1.1 The ebXML Initiative Background on this initiative 
1.2 Document Purpose and Scope 
1.3 References and Related Efforts To other documents 
2 Requirements for an ebXML Compliant Application 
2.1 General 
2.2 Application to Application 
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 
2.3.1 Functional 
2.3.2 Non-functional 
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. 
3.2 Technical Architecture 
3.3 Core Components 
3.4 Transport/Routing and Packaging 
3.5 Registry and Repository 
3.6 Business Process Methodology 
4 Requirements for ebXML Technical Coordination & Support Single point of contact, etc.
5 Requirements for ebXML Marketing, Awareness & Education [Is this appropriate for this type of document? I tend to think it is outside the scope of this document, and am not quite sure what I would put here] 
6 ebXML Work Group Deliverables A listing of the specific guidelines to be produced, with brief description.