1 / 39

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

UN/CEFACT Forum Wednesday, 16 March 2005 Lunch & Learn. ATG XML NDR Mark Crawford ATG2 Chair. UN/CEFACT. 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. Outline. The Role of ATG

Télécharger la présentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. 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

  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. TBG_ TBG17 RSM, Models, Spreadsheets Harmonization XMI, RSM, Spreadsheets Storage ICG XMI, RSM, Spreadsheets Syntax Solution TBG_/ATG 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. 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.

  18. 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

  19. 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

  20. 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

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

  22. 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

  23. 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

  24. 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

  25. 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

  26. 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

  27. 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

  28. 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

  29. 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

  30. 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

  31. 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.

  32. 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.

  33. 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.

  34. 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

  35. 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

  36. 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

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

  38. Thank You!

More Related