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

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

Define the measure of success for this initiative

[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]

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

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

• 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?"]

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

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!"].

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

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

[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?]

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

[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?]

[Ed. Note - At least one member feels this requirement is unclear as written]

[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

• 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?]

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

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

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

[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?]

• 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

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]

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.