UN/CEFACT Forum Wednesday, 16 March 2005 Lunch & Learn ATG XML NDR Mark Crawford ATG2 Chair U NITED N ATIONS C ENTRE F OR T RADE F ACILITATION A ND E LECTRONIC B USINESS Under the auspices of United Nations Economic Commission for Europe UN/CEFACT

P A G E 2  UN/CEFACT, March 2005 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

P A G E 3  UN/CEFACT, March 2005 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

P A G E 4  UN/CEFACT, March 2005 ATG2 Mission The mission of ATG2 is to create and maintain the trade, business and administration document structures that are deployed by XML

P A G E 5  UN/CEFACT, March 2005 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

P A G E 6  UN/CEFACT, March 2005 Creating XSD TBG_ RSM, Models, Spreadsheets Harmonization TBG17 Storage ICG XMI, RSM, Spreadsheets Syntax Solutio n XMI, RSM, Spreadsheets TBG_/ATG

P A G E 7  UN/CEFACT, March 2005 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

P A G E 8  UN/CEFACT, March 2005 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

P A G E 10  UN/CEFACT, March 2005 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

P A G E 11  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

P A G E 12  UN/CEFACT, March 2005 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

P A G E 13  UN/CEFACT, March 2005 The Modules

Schema Module Relationships

P A G E 15  UN/CEFACT, March 2005 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

P A G E 16  UN/CEFACT, March 2005 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

P A G E 18  UN/CEFACT, March 2005 General Namespace Structure urn:un:unece:uncefact: : : : –Namespace Identifier (NID) = un –Namespace Specific String = –unece:uncefact: : : : 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 = 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.

P A G E 19  UN/CEFACT, March 2005 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

P A G E 20  UN/CEFACT, March 2005 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

P A G E 21  UN/CEFACT, March 2005 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

P A G E 22  UN/CEFACT, March 2005 Minor Versions Minor versions will be increased when compatible changes occur –Adding values to enumerations –Optional extensions –Add optional elements

P A G E 23  UN/CEFACT, March 2005 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

P A G E 24  UN/CEFACT, March 2005 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

P A G E 25  UN/CEFACT, March 2005 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

P A G E 26  UN/CEFACT, March 2005 Component Management Solution: Types of Naming Conventions Schema Module Naming Conventions –Each UN/CEFACT internal Schema Module MUST be named: {ParentSchemaModuleName}{InternalSchemaModuleFunction}{S chema Module} Element Naming Conventions –Explicitly derived from ISO BIE constructs (BIE Properties & ASBIEs) Attribute Naming Conventions –Explicitly derived from ISO Supplementary Components Type Naming Conventions –Explicitly derived from ISO BIE constructs, or –Explicitly derived from ISO Data Types

P A G E 27  UN/CEFACT, March 2005 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

P A G E 28  UN/CEFACT, March 2005 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

P A G E 29  UN/CEFACT, March 2005 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 Solution –Define standardized documentation sets for each construct Approach –Use CCTS Section 7 as sole documentation requirement

P A G E 30  UN/CEFACT, March 2005 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

P A G E 31  UN/CEFACT, March 2005 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

P A G E 32  UN/CEFACT, March 2005 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.

P A G E 33  UN/CEFACT, March 2005 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.

P A G E 34  UN/CEFACT, March 2005 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.

P A G E 35  UN/CEFACT, March 2005 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

P A G E 36  UN/CEFACT, March 2005 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

P A G E 37  UN/CEFACT, March 2005 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

P A G E 38  UN/CEFACT, March 2005 Implementation Verification

P A G E 39  UN/CEFACT, March 2005