Members of the eBTWG Core Component Project Team have published a new public-review draft of its Core Components Technical Specification, Part 1, which "contains information to guide in the interpretation or implementation of ebXML concepts." The eBTWG Core Components Specification Project Team operates under the UN/CEFACT Electronic Business Transition Working Group, and has been formed to produce: (1) a consolidated ebXML Core Components Technical Specification that incorporates the material in the ebXML Discovery and Analysis, Naming Convention, and Context technical reports adds material related to Metadata Definition; (2) a specification for and the beginning lexicon of core components. The CC system is designed to ensure that two trading partners using different (XML/EDI) syntaxes are using business semantics in the same way. "The UN/CEFACT Core Component solution presented in the specification presents a methodology for developing a common set of semantic building blocks that represent the general types of business data in use today; it forms the basis for standards development work of business analysts, business users and information technology specialists supplying the content of and implementing applications that will employ the UN/CEFACT Core Component Library (CCL)."

Bibliographic information: "Core Components Technical Specification, Part 1." By eBTWG CC Project Team Participants. United Nations Centre for Trade Facilitation and Electronic Business. Draft Version 1.7. 31-October-2001. 92 pages.

The key concepts in the Core Components Technical Specification [excerpted]:

• Core Component: The Core Component is a semantic building block that is used as a basis to construct all electronic business messages -- a building block for the creation of a semantically correct and meaningful information exchange 'parcel'. It contains only the information pieces necessary to describe a specific concept.
• Context: Context is a mechanism for classifying business situations. Once business contexts are identified, the appropriate core components can be selected or created and differentiated to indicate any necessary qualification and refinement needed to support the business process in a given context.
• Business Information Entity: When a Core Component is used in a real business situation, it is used to define a Business Information Entity. The BIE is the result of using a core construct within a specific business context. A BIE is [thus] a piece of business data or a group of pieces of business data with a unique business semantic definition. A BIE can be either a Basic Business Information Entity (BBIE) or an Aggregate Business Information Entity (ABIE).
• Repository Metadata: Core Components, Context Categories and Business Information Entities along with syntax bound business message descriptions are available in the repository. The relationships between these objects are stored to encourage standard use and re-use at all levels.

From the draft version 1.7 Executive Summary: "This Core Component technical specification provides a way to identify, capture and maximize the reuse of business information to support and enhance information interoperability across multiple business situations. The specification focuses both on human-readable and machine-processable representation of this information. The system is more flexible than current standards in this area because the semantic standardisation is done in a syntax-neutral fashion. UN/CEFACT can guarantee that two trading partners using different syntaxes (e.g., XML and EDIFACT) are using business semantics in the same way. This enables clean mapping between disparate message definitions across syntaxes, industry and regional boundaries. UN/CEFACT Business Process and Core Component solutions capture a wealth of information about the business reasons for variation in message semantics and structure. In the past, such variations have introduced incompatibilities. The core components mechanism uses this rich information to allow identification of exact similarities and differences between semantic models. Incompatibility becomes incremental rather than wholesale, i.e., the detailed points of difference are noted, rather than a whole model being dismissed as incompatible."