Core Components and More Good Afternoon. Thank you for joining us. As you can see, there are a lot of folks involved in this presentation. Let me introduce them.

International Standards – Core Components Technical Specification – both ISO and UN/CEFACT Goal is global registry Thousands of Candidates submitted Harmonization at UN/CEFACT Now we’ll leave modeling, for the moment, and go on to Core Components. My job is to give you some basic information, or education, about modeling and Core Components. My co-presenters will give you actual application of these two methodologies. The Core Component Technical Specification, or CCTS, is an approved publication from UN/CEFACT and ISO. Our goal is the global registry we discussed earlier. Thousands of Candidate CCs have been submitted to a team at UN/CEFACT; this team is working to harmonize those submissions into common Core Components to be put into the global registry. This is not an easy task!

Core Components Basic building block – a data element No business context Types ACC = Aggregate Core Component Like a segment in X12 or EDIFACT BCC = Basic Core Component Like a data element in X12 or EDIFACT ASCC = Associate Core Component Connects two ACCs Like a Party to an Address Just a little education, for those of you who haven’t had the joy of working on or reading the CCTS. I hope that you’re familiar with EDI? An ACC, or Aggregate Core Component is like a segment, or a segment group, or a loop. It’s a collection of business data that logically works together. But without the business context. Within an ACC, are BCCs, Basic Core Components. These are like data elements. Think back on the example we saw earlier. The Object Class was Address; we have an ACC for Address. And within it are a lot of BCCs; the ones that you would all be able to figure out. Street, City, PO Box, and so on.

Business Information Entities Built from Core Components Have Business Context (8 possible) Like Trade, Purchasing, Switzerland Types ABIE = Aggregate Business Information Entity Built from an ACC Qualified with a meaningful term BBIE = Basic Business Information Entity Built from a BCC ASBIE= Association Business Information Entity Connects two ABIEs Built from an ASCC Just a little education, for those of you who haven’t had the joy of working on or reading the CCTS. I hope that you’re familiar with EDI? An ACC, or Aggregate Core Component is like a segment, or a segment group, or a loop. It’s a collection of business data that logically works together. But without the business context. Within an ACC, are BCCs, Basic Core Components. These are like data elements. Think back on the example we saw earlier. The Object Class was Address; we have an ACC for Address. And within it are a lot of BCCs; the ones that you would all be able to figure out. Street, City, PO Box, and so on.

Core Components as Canonical Model X12 DE 116 EDIFACT DE 3251 If you are involved in traditional EDI, or even in XML, you know that you might have to use many variations of either or both of them. This adds cost, both in time and resources, but is also an excellent to increase the possibility of error. This slide shows just a small fraction of the possibilities. TDED RosettaNet NationalPostalCode DE 3251

TBG17 Submission for Address For Postal Code UBL (OASIS) submitted Postal_Zone OAGi submitted Postal Code Construction submitted Postcode CC Harmonization agreed on And actual example of submissions is Postal Code. UBL, which is a committee within OASIS, and the Open Applications Group, and the Construction industry all submitted postal code. But you see that each group had a different name for the same thing. At UN/CEFACT, the harmonization team agreed to call it Postcode; and the other two terms are shown as business terms in the dictionary. Address. Postcode. Code

Core Components as Canonical Model EDIFACT DE 3251 X12 DE 116 UN00000014 Address. Postcode. Code However, once syntax neutral Core Components are available on a global level, and each has it‘s own Unique Identifier, we can use that UID to connect every syntax to every other syntax. This is the vision of ebXML Core Components. And what is will provide is Interoperability. Saving all of us time and money. TDED DE 3251 RosettaNet NationalPostalCode This is genuine INTEROPERABILITY

SYNTAX NEUTRAL!!! Naming Conventions The dictionary is Unique ID Dictionary Entry X12 EDIFACT XML UN00000014 UN00000033 Address. Postcode. Code Address. Street Name. Text DE 116 DE 166 DE 3251 DE 3042 ZipCode Street One part of the Core Components Technical Specification is called Naming Conventions. These follow an international standard from ISO, and they provide the rules and procedures for naming the dictionary entries. Each entry, that is each Core Component, will have a unique identifier. This is the exciting idea behind Core Components. Because, as you can see, the dictionary is syntax neutral. We finally have an automated way to communicate and understand each other , no matter what format we use. SYNTAX NEUTRAL!!! The dictionary is

UN/CEFACT Library Maintenance 9

Maintenance Procedure Upgrade Reorganisation Maintenance Procedure Upgrade Clarify procedures to lower barriers for participation Increase speed of library publication Need to increase limited resources for library work Need complete methodology for all aspects of library maintenance Alignment of deletion/deprecation procedures Include alignment / harmonisation of libraries and publication cycles in maintenance procedures 10

The Libraries Three Libraries CCL TDED Joint Maintenance Agency Reference Models Code lists Three Libraries XML Schema EDIFACT CCL TDED Joint Maintenance Agency (UNECE and ISO TC154) “Libraries” also refers to code lists and XML schema. 11

Library Linkages UN/EDIFACT DE 7065 Package Type Description Code TDED DE 7065 Package. Type. Code CCL BCC Package. Type. Code/TDED Link 7065 12

Maintenance Steps The following steps apply to all requests for changes to existing libraries/code lists/directories: Change request(s) submitted and logged Technical assessment Semantic assessment Harmonization Update of libraries/code lists/directories Validation of updated libraries/code lists/directories Quality Assurance (internal review) Formal Validation (external review) Publication 13