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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-core message

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


Subject: Draft scope statement


TO:  ebXML Core Components Project Team

We listed a scope of work statement as one of the deliverables in our 
meeting in Orlando earlier this month.  You will find a proposed statement 
given below and attached in HTML format (James -- if appropriate, could you 
please post on the team's web site?)  Many thanks go to Sharon Kadlec for 
her valuable help with the text.  Your comments and suggestions are of 
course welcome.  Best regards.

Alan Kotok
akotok@disa.org
+1 703-518-4174

==========================

Core Components Project Team
Scope of work, draft, 18 February 2000

Summary

The Core Components Project Team will identify and define those items 
considered common across XML business data exchanges. Common items are 
semantic units at any level that stay consistent across contexts, and 
therefore are reusable both within and between business exchange messages. 
Business process models will help define common items and provide their 
context. This context will in turn define the precise use of common items 
in messages exchanged among parties. The team will describe these items in 
terms independent of implementation syntax, and thus should apply equally 
to XML (or SGML) documents, as well as EDI transactions.
The team will adopt -- or if needed, develop -- a methodology to 
consistently build or derive core components, including methods to 
encourage reuse and provide for extensions. In concert with the Business 
Process Project Team, this group will identify element names that can apply 
across business processes and contexts, yet still allow for translation 
into leading spoken languages. The work will generate the content of core 
components independent of implementation syntax, but with references to 
data structures in XML messages and EDI transactions. The team will 
identify attributes that describe the context of the components also in 
terms independent of syntax. Team participants will produce samples of core 
components and describe their representation in XML messages and EDI 
transactions.

Objectives

By the completion of the second working meeting (12 May 2000), the Core 
Components Project Team will 

       Complete the scope and project plan
       Propose a methodology for consistently identifying common 
components and attributes describing context
       Propose methods for reusing and extending core components
       Propose the core component and context attribute content

Out of scope items

Business processes. Development of business process models that identify 
potential reusable components. The business process team should develop the 
models that define and describe business semantics, but still point out 
those semantics with potential for reusability across messages

Technical architecture. Description of the overall framework and 
conventions for expressing core components in XML messages both in the 
business and technical content.
  For business content, the technical architecture team should distinguish 
between common and business-specific components, if such a distinction is 
needed. The overall architecture for data exchange will need flexibility to 
meet the demands of Web customers, yet still need to support known business 
application and integration requirements as systems and tools mature.

Transport, packaging, routing. Description of common items used in message 
headers, security features, transport protocols, and error messages. While 
some core components may appear in transport, packaging, and routing 
operations, these messages will likely have specific syntax and invocation 
requirements that will require separate processing from the normal message 
body.

Registry and repository. Specifications for submission and retrieval of 
core components in repositories. The registry and repository team should 
describe the processes and methods for the identification or registration 
of core components in repositories

Dependencies
1. A defined set of requirements for ebXML overall
2. Business process models that identify reusable objects
3. Naming conventions for technical and business content in the technical 
architecture
4. Requirements for listing common objects in component libraries and 
repositories
Title: ebXML core components team scope, draft, 18 Feb 2000

Core Components Project Team

Scope of work, Draft, 18 February 2000

Summary

The Core Components Project Team will identify and define those items considered common across XML business data exchanges. Common items are semantic units at any level that stay consistent across contexts, and therefore are reusable both within and between business exchange messages. Business process models will help define common items and provide their context. This context will in turn define the precise use of common items in messages exchanged among parties. The team will describe these items in terms independent of implementation syntax, and thus should apply equally to XML (or SGML) documents, as well as EDI transactions.

The team will adopt -- or if needed, develop -- a methodology to consistently build or derive core components, including methods to encourage reuse and provide for extensions. In concert with the Business Process Project Team, this group will identify element names that can apply across business processes and contexts, yet still allow for translation into leading spoken languages. The work will generate the content of core components independent of implementation syntax, but with references to data structures in XML messages and EDI transactions. The team will identify attributes that describe the context of the components also in terms independent of syntax. Team participants will produce samples of core components and describe their representation in XML messages and EDI transactions.

Objectives

By the completion of the second working meeting (12 May 2000), the Core Components Project Team will

  • Complete the scope and project plan
  • Propose a methodology for consistently identifying common components and attributes describing context
  • Propose methods for reusing and extending core components
  • Propose the core component and context attribute content

Out of scope items

Business processes. Development of business process models that identify potential reusable components. The business process team should develop the models that define and describe business semantics, but still point out those semantics with potential for reusability across messages

Technical architecture. Description of the overall framework and conventions for expressing core components in XML messages both in the business and technical content. . For business content, the technical architecture team should distinguish between common and business-specific components, if such a distinction is needed. The overall architecture for data exchange will need flexibility to meet the demands of Web customers, yet still need to support known business application and integration requirements as systems and tools mature.

Transport, packaging, routing. Description of common items used in message headers, security features, transport protocols, and error messages. While some core components may appear in transport, packaging, and routing operations, these messages will likely have specific syntax and invocation requirements that will require separate processing from the normal message body.

Registry and repository. Specifications for submission and retrieval of core components in repositories. The registry and repository team should describe the processes and methods for the identification or registration of core components in repositories

Dependencies

  1. A defined set of requirements for ebXML overall
  2. Business process models that identify reusable objects
  3. Naming conventions for technical and business content in the technical architecture
  4. Requirements for listing common objects in component libraries and repositories

 



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

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC