Slide 1

Slide 2

Slide 3

Core Components grew out of the ebXML (“Electronic Business using XML”) initiative

ebXML produced a modular suite of specifications in multiple areas

ebXML produced a modular suite of specifications in multiple areas (cont’d)

The ebXML “Functional Service View”shows several of these specifications in action

After May 2001, the continuation of ebXML was “split” between UN/CEFACT and OASIS

Slide 9

The UN/CEFACT Core Components Specification v1.9 (“CCTS”) is currently in the final stages of approval under the UN/CEFACT Open Development Process

CCTS specifies a new approach to the well-understood problem of the lack of information interoperability between applications in the e-business arena

Slide 12

A Core Component is a building block for the creation of a semantically correct and meaningful information exchange package

All Core Component naming conventions conform to the guidelines and principals described in the ISO/IEC 11179 standard Part 5: “Naming and Identification Principals for Data Elements”

All Core Component naming conventions conform to the guidelines and principals described in the ISO/IEC 11179 standard Part 5: “Naming and Identification Principals for Data Elements” (cont’d)

Additional name parts known as “qualifiers” are used when needed

Related Core Components are grouped together to form “Aggregate Core Components” (ACCs)

A “Core Component Type” (CCT) is another category of Core Component

A “Core Component Type” (CCT) is another category of Core Component (cont’d)

Each Core Component Type contains one “Content Component” and one or more “Supplementary Components”

Each Core Component Type contains one “Content Component” and one or more “Supplementary Components” (cont’d)

Core Component Types may be restricted – this is the function of a “Data Type”

A Data Type may restrict of the set of values of a Core Component Type’s Content Component and/or Supplementary Component(s)

The CCTS contains a list of valid Content Component Restrictions based on Core Component Type on which the Data Type is based

When an Aggregate Core Component is contained within another Aggregate Core Component, an “Association Core Component” (ASCC) is used

This example results in multiple Core Components

The following figure summarizes the constructs discussed thus far, and the relationships between them

Slide 28

When a Core Component is used in a real business circumstance, it serves as the basis for a “Business Information Entity” (BIE)

When a Core Component is used in a real business circumstance, it serves as the basis for a “Business Information Entity” (BIE) (cont’d)

The following figure depicts the Core Components Context Mechanism

The Business Information Entity structures “parallel” some of the Core Component structures

As with Aggregate Core Components, related Basic Business Information Entities are grouped together to form “Aggregate Business Information Entities” (ABIEs)

When an Aggregate Business Information Entity is contained within another Aggregate Business Information Entity, an “Association Business Information Entity” (ASBIE) is used

This example results in multiple Business Information Entities

The UN/CEFACT vision is that “all Core Components will be recorded in an ebXML-compliant registry and stored in a related repository”

Slide 37

The CCTS also includes other features that are not discussed today

Slide 39

The OASIS Universal Business Language (UBL) TC is basing its work on the Core Components Methodology

The UN/CEFACT Applied Technology Group 2 (ATG 2) group is defining an XML serialization for Core Components

The OASIS Content Assembly Mechanism (CAM) TC is working to provide a generic standalone “content assembly mechanism”

Slide 43

The “Core Components Review” Subcommittee of the OASIS/ebXML Registry TC is responsible for “Core Component-enabling” the OASIS/ebXML Registry architecture

The following are some “early glimpses” of how Core Components will be implemented in the OASIS/ebXML Registry architecture

Slide 46

The OASIS/ebXML Registry Version 2.5 Specifications just became OASIS TC-Approved Specifications

The Cooperating Registries feature enables multiple ebXML registries to participate together in a “federation”

The Event Notification feature provides “publish/subscribe” capabilities to ebXML Registry

The HTTP Binding feature provides a “SOAP-less” Web interface to ebXML Registry

The Content Management Services feature provides content validation and cataloging capabilities to ebXML Registry

The eXtensible Access Control Markup Language (XACML) Support feature allows fine-grained access control policies to be defined for ebXML Registry

Slide 53

Contact Information