un/cefact forum wednesday, 16 march 2005 lunch & learn atg xml ndr mark crawford atg2 chair u...

UN/CEFACT ForumUN/CEFACT ForumWednesday, 16 March 2005Wednesday, 16 March 2005

Lunch & Learn Lunch & Learn

ATG XML NDRMark Crawford

ATG2 Chair

UNITED NATIONS CENTRE FOR TRADE FACILITATION AND ELECTRONIC BUSINESSUnder the auspices of United Nations Economic Commission for Europe

UN/CEFACTUN/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


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


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


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


Creating XSD

TBG_

RSM, Models, Spreadsheets

Harmonization

TBG17

StorageICG

XMI, RSM, Spreadsheets

Syntax Solutio

n

XMI, RSM, Spreadsheets

TBG_/ATG

P A G E 7


Outline

• The Role of ATG

Supporting CEFACT Methodology• Maximizing Reuse




• Documentation



P A G E 8


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


xsd:complexType

xsd:element

xsd:element

Core Component Type (CCT)

Specifies restrictions on

Data Type (DT)

Basic Core Component (BCC)

Aggregate Core Component (ACC)

Association Core Component (ASCC)

Defines a set of values of

As Property aggregated

in

Further restricts

Based

Is Based

On

xsd:complexType

xsd:complexType or

xsd:simpleType

xsd:(root)element

Data Type (DT)

Basic Business Information Entity (BBIE)

Aggregate Business Information Entity (ABIE)

Association Business Information Entity (ASBIE)

Defines a set of values of

Message Assembly

Aggregated in

Qualified and Unqualified Data Types

Assembly Component

Adds extra information

Aggregated in

Is Based On

As Propertyaggregated

in

Is

On

Context Neutral Context Specific Syntax Specific

QualifiesThe

ObjectClass

Of

P A G E 10


Outline

• The Role of ATG


Maximizing Reuse Managing Namespaces



• Documentation



P A G E 11


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


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


The Modules

Schema ModuleType

File

Namespace

W3C XML Schema

1

1

1

1..*

Root Schema Module

Internal Schema Module

Reusable ABIE Module

Unqualified Data Type Module

Qualified Data Type Module

Identifier List Module

Code List Module

Core Component Type Module

Other Standards Body ABIE Module

SchemaModule Relationships

P A G E 15


Outline

• The Role of ATG



Managing Namespaces• Supporting Different Versions


• Documentation



P A G E 16


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


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.

P A G E 19


Outline

• The Role of ATG




Supporting Different Versions• Creating Reusable Components

• Documentation



P A G E 20


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


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


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


Outline

• The Role of ATG





Creating Reusable Components

• Documentation



P A G E 24


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


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


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

P A G E 27


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


Outline

• The Role of ATG






Documentation• Standardizing the Instances


P A G E 29


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

P A G E 30


Outline

• The Role of ATG






• Documenting the Components

Standardizing the Instances• What About Codes and Identifiers

P A G E 31


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


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


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


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


Outline

• The Role of ATG





• Documenting the Components


What About Codes and Identifiers

P A G E 36


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


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


Implementation Verification

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

P A G E 39


un/cefact forum wednesday, 16 march 2005 lunch & learn atg xml ndr mark crawford atg2 chair u...

Documents

uncefact forumwednesday

business process

root schema

business exchangecreate

conformant core components

message structures

reusable componentsxml

trade facilitation