UN/CEFACT Forum Wednesday, 16 March 2005 Lunch & Learn

UN/CEFACT ForumWednesday, 16 March 2005 Lunch & Learn ATG XML NDR Mark Crawford ATG2 Chair UN/CEFACT UNITED NATIONS CENTRE FOR TRADE FACILITATION AND ELECTRONIC BUSINESS Under the auspices of United Nations Economic Commission for Europe

Outline • The Role of ATG • Supporting CEFACT Methodology • Maximizing Reuse • Managing Namespaces • Supporting Different Versions • Creating Reusable Components • Documentation • Standardizing the Instances • What About Codes and Identifiers

ATG • Creation and maintenance of the trade, business and administration document structures that are deployed by a specific technology or standard such as: • UN/EDIFACT • UN Layout Key • UN e-docs • XML

ATG2 Mission • The mission of ATG2 is to create and maintain the trade, business and administration document structures that are deployed by XML

ATG2 Deliverables • XML naming conventions and design rules, including XML syntax extension methodology and XML message assembly • XML schema for message structures and reusable components • XML schemas for describing Business Process and Information Models, to include Core Components and Business Information Entities, as stored in the Registry/Repository • XML syntax expression of the Core Component Technical Specification context constraint language • Technical Assessment Checklist for XML syntax deliverables • XSL Stylesheets as required

TBG_ TBG17 RSM, Models, Spreadsheets Harmonization XMI, RSM, Spreadsheets Storage ICG XMI, RSM, Spreadsheets Syntax Solution TBG_/ATG Creating XSD

Supporting CEFACT Methodology • Business Requirements • Provide XML that instantiates the TBG methodologies • Minimize requirements on TBG • Solution • Closely couple UN/CEFACT XML design rules with the ebXML Core Components Technical Specification • Approach • Generate schema from fully conformant Business Information Entities that are based on fully conformant Core Components as stored in the UN/CEFACT Library • Determine optimized use of Schema options and develop production rules

Solution – Transformation Rules UN/CEFACT, March 2005

Maximizing Reuse • Business Requirements • Support domain specific requirements • Support context • Minimize maintenance requirements • Minimize cross-domain management issues while preserving cross-domain interoperability • Promote reuse • Maximize performance • Solution • Develop modularity approach that supports levels of aggregation

Maximizing Reuse • Approach • Create a root schema for each business exchange • Create 4 levels of reuse that are chosen by process owner • Single process • Related processes • Cross functional processes • External components • Reuse individual schemas without having to import the entire CEFACT schema library • Allow each schema to define its own dependencies • Identify logical associations between schema modules

The Modules

SchemaModule Relationships

Managing Namespaces • Business Requirements • Support the modularity model • Provide persistent, fixed namespace scheme that supports registry requirements • Optimize XML processor performance considerations • Ensure business partners can easily understand components of namespace string • Solution • Every schema module will have its own fully described namespace • Exception - limited reuse modules will be in the same namespace as the root schema • Use Uniform Resource Names vice Uniform Resource Locators • Include: Name, Token, Location, Versioning details • Approach • Define UN/CEFACT namespace scheme in conjunction with UN and UN/ECE

General Namespace Structure • urn:un:unece:uncefact:<schematype>:<status>:<name>:<version> • Namespace Identifier (NID) = un • Namespace Specific String = • unece:uncefact:<schematype>:<status>:<name>:<version> with unece and uncefact as fixed value second and third level domains within the NID of un • schematype = a token identifying the type of schema module: data|process|codelist|identifierlist|documentation • status = the status of the schema as: draft|standard • name = the name of the module (using upper camel case) • version = <major>.<minor>.[<revision>] • major = The major version number. Sequentially assigned, first release starting with the number 1. • minor = The minor version number within a major release. Sequentially assigned, first release starting with the number 0. Not applicable for code list or identifier list schema. • revision = Sequentially assigned alphanumeric character for each revision of a minor release. Only applicable where status = draft. Not applicable for code list or identifier list schema.

Versioning • Business Requirements • Different trading partners will use different versions • Changes should minimize impact on systems • Versions should be clearly defined • Solution • Enable polymorphic processing • Approach • Define categories of changes for major and minor versions

Major Versions • Will be increased when incompatible changes occur • Removing or changing values in enumerations • Changing of element names, type names and attribute names • Changing the structures so as to break polymorphic processing capabilities • Deleting or adding mandatory elements or attributes • Changing cardinality from mandatory to optional

Minor Versions • Minor versions will be increased when compatible changes occur • Adding values to enumerations • Optional extensions • Add optional elements

Creating Reusable Components • Business Requirements • Users must be able to semantically understand constructs • Constructs should be consistently used and named • Processing should be optimized • Solution • Develop naming and design rules that optimize and standardize XSD constructs • Approach • Determine component management solution • Determine naming rules • Determine construct rules

Component Management Solution:Global vs Local • All element declarations must be local except for a root element that must be declared globally • Impact: • We are managing by types, not by types and elements • Unlike typical local element schemes, all UN/CEFACT local elements will be strictly controlled (tied to a specific BBIE or ASBIE) to ensure that they can not be confused • But – We are exploring how to harmonize with UBL

Component Management Solution:Types of Naming Conventions • Schema Module Naming Conventions • Each UN/CEFACT internal Schema Module MUST be named: {ParentSchemaModuleName}{InternalSchemaModuleFunction}{Schema Module} • Element Naming Conventions • Explicitly derived from ISO 15000-5 BIE constructs (BIE Properties & ASBIEs) • Attribute Naming Conventions • Explicitly derived from ISO 15000-5 Supplementary Components • Type Naming Conventions • Explicitly derived from ISO 15000-5 BIE constructs, or • Explicitly derived from ISO 15000-5 Data Types

Component Management Solution: XSD Construct Rules • Complex Types reflect their BIE counterparts • Content of the Complex Types will be exact replications • Changes to the constructs will require changes to the model

Documentation • Business Requirements • Business Users must understand the details of each schema construct • Business users should not have to deal with different details in different syntaxes • TBG groups should not have to provide more documentation than is required by ISO 15000-5 • Solution • Define standardized documentation sets for each construct • Approach • Use CCTS Section 7 as sole documentation requirement

Outline • The Role of ATG • Supporting CEFACT Methodology • Maximizing Reuse • Managing Namespaces • Supporting Different Versions • Creating Reusable Components • Documenting the Components • Standardizing the Instances • What About Codes and Identifiers

Instance Document Rules • Requirements • Business users should expect instances to be standard • Business users should trust that instances are complete • Solution • Provide instance rules • Approach • Character Encoding • Empty elements

Instance Document Rules:Character Encoding • In conformance with ISO/IETF/ITU/UNCEFACT Memorandum of Understanding Management Group (MOUMG) Resolution 01/08 (MOU/MG01n83) as agreed to by UN/CEFACT, all UN/CEFACT XML will be instantiated using UTF. UTF-8 is the preferred encoding, but UTF-16 may be used where necessary to support other languages.

Instance Document Rules:Empty Content • Empty elements do not provide the level of assurance necessary for business information exchanges and as such, will not be used. • UN/CEFACT conformant instance documents MUST NOT contain an element devoid of content. • The xsi:nil attribute MUST NOT appear in any conforming instance.

Instance Document Rules:Substitution • The xsi:type attribute allows for substitution during an instantiation of a xml document. In the same way that substitution groups are not allowed, the xsi:type attribute is not allowed. • The xsi:type attribute MUST NOT be used.

Outline • The Role of ATG • Supporting CEFACT Methodology • Maximizing Reuse • Supporting Different Versions • Creating Reusable Components • Documenting the Components • Standardizing the Instances • What About Codes and Identifiers

Code and Identifiers List • Business Requirements • Some users require XML Processor validation • Some users only want application validation • Code and Identifier changes should not require new schema • Restrictions of Code Lists should be easy • Lists should only have to be created once • Solution • Establish code and identifier schema modules • Leverage external lists wherever possible • Approach • Define normative form schema module and negotiate with all external code list owners to adopt and publish

Sample Code List Rules • All codes must be part of a UN/CEFACT or external maintained code list • External code lists must be used wherever possible • The Library may design and use an internal code list where an existing external code list needs to be extended, or where no suitable external code list exists • All UN/CEFACT maintained or used code lists must be enumerated using the UN/CEFACT code list schema module template

Implementation Verification http://www.disa.org/cefact-groups/atg/downloads/index.cfm

Thank You!

UN/CEFACT Forum Wednesday, 16 March 2005 Lunch & Learn