UN/CEFACT Forum Wednesday, 16 March 2005 Lunch

1
UN/CEFACT ForumWednesday, 16 March 2005 Lunch
Learn
UN/CEFACT

• ATG XML NDR
• Mark Crawford
• ATG2 Chair

UNITED NATIONS CENTRE FOR TRADE FACILITATION AND
ELECTRONIC BUSINESS Under the auspices of United
Nations Economic Commission for Europe
2
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

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

4
ATG2 Mission

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

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

6
Creating XSD
7
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

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

9
Solution Transformation Rules
?UN/CEFACT, March 2005
10
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

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

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

13
The Modules
14
SchemaModule Relationships
15
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

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

17
(No Transcript)
18
General Namespace Structure

• urnununeceuncefactltschematypegtltstatusgtltnamegt
  ltversiongt
• Namespace Identifier (NID) un
• Namespace Specific String
• uneceuncefactltschematypegtltstatusgtltnamegtltversi
  ongt 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 dataprocesscodelistidentifierlis
  tdocumentation
• status the status of the schema as
  draftstandard
• name the name of the module (using upper camel
  case)
• version ltmajorgt.ltminorgt.ltrevisiongt
• 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.

19
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

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

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

22
Minor Versions

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

23
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

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

25
Component Management SolutionGlobal 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

26
Component Management SolutionTypes of Naming
Conventions

• Schema Module Naming Conventions
• Each UN/CEFACT internal Schema Module MUST be
  named ParentSchemaModuleNameInternalSchemaMod
  uleFunctionSchema 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

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

28
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

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

30
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

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

32
Instance Document RulesCharacter 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.

33
Instance Document RulesEmpty 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 xsinil attribute MUST NOT appear in any
  conforming instance.

34
Instance Document RulesSubstitution

• The xsitype attribute allows for substitution
  during an instantiation of a xml document. In
  the same way that substitution groups are not
  allowed, the xsitype attribute is not allowed.
• The xsitype attribute MUST NOT be used.

35
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

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

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

38
Implementation Verification
http//www.disa.org/cefact-groups/atg/downloads/in
dex.cfm
39
Thank You!