UN/CEFACTTechnical Update

AFACT TMC22 May 2019

Bangkok (Thailand)

UN/CEFACT Formation Programee Development Area (PDA) Core Component Library (CCL)

Message Construction Guideline Project Project Proposal Requirement Gathering

New EDI Platform (Web API) edi3.org API Town Plan project RDM to API project

TOPICs

UN/CEFACT Formation

PDA Project Status (1)(1) ITP (International Trade Procedure) Rec.37 (Single Submission Portal) completed. Rec.33 (Single Window Recommendation) to be Public Review White Paper on Integrated Service for M&SME in International Trade

(2) ISC (International Supply Chain) Rec.43 (Sustainable Procurement) completed Buy-Ship-Pay RDM (Reference Data Model) al,ost completed Cross Industry Delivery to be Public Review BRS of PO Finance completed RDM for Accounting & Audit project started Orchestral Focal Point EDI on Web API

(3) Regulatory White Paper on Blockchain completed Ledger Interoperability project started Project for Waste Management on going

(4) Sectoral Green Paper on Sustainable Tourism completed BRS for eQuality Certificate completed Sustainable Textile and Leather Traceability and Transparency

project launched

(5) M&T (Methodology and Technology) Code Management User Guide completed Message Construction Guide project launched

PDA Project Status (2)

CCL 2019A publishedCC：7,906BIE : 12,784 qDT : 160

Newly registered BIEs (CCL2018A~CCL2019A)Scheduling (For JIT Manufacturing)Traceability (For Agriculture) SCRDM (Supply Chain Reference Data Model)FLUX (Fisheries Language for Universal eXchange) eQuality (Quality Certificate for Export)Additional BIEs for Tax regulation

CCL (Core Component Library) Status

Message Construction Guideline Project

CCL

CCTS

NDRCCBDA

Message AssemblyMA

Message BIEMBIE

Aggregate BIEABIE

ASMA

ASBIE

ASMBIE

An MA is the logical root of a message structure. An MA consists of one or more ASMAs each of which is an association to an MBIE.

An MBIE defines which properties of an ABIE are to be included. The content model of an MBIE may be the same as, or may be a subset of, the content model of an ABIE.The structure of an MBIE (e.g. the repetition of its properties i.e. its MBBIEs andASMBIEs) may be restricted with regard to the underlying ABIE

CCBDA

RestrictionsABIE CI_ Trade_ Product. DetailsBBIE CI_ Trade_ Product. Identification. Identifier Not UsedBBIE CI_ Trade_ Product. Global_ Identification. IdentifierBBIE CI_ Trade_ Product. Seller Assigned_ Identification. Identifier Not UsedBBIE CI_ Trade_ Product. Buyer Assigned_ Identification. IdentifierBBIE CI_ Trade_ Product. Manufacturer Assigned_ Identification. IdentifierBBIE CI_ Trade_ Product. Name. Text => Limited Occurrence (0..1)BBIE CI_ Trade_ Product. Trade_ Name. Text Not UsedBBIE CI_ Trade_ Product. Description. TextBBIE CI_ Trade_ Product. Type. Code => Specific CodelistBBIE CI_ Trade_ Product. Net Weight. Measure Not UsedBBIE CI_ Trade_ Product. Gross Weight. Measure Not UsedBBIE CI_ Trade_ Product. Drained_ Net Weight. Measure Not UsedBBIE CI_ Trade_ Product. Brand_ Name. Text Not UsedBBIE CI_ Trade_ Product. Sub-Brand_ Name. Text Not UsedBBIE CI_ Trade_ Product. Product Group. Identifier Not UsedBBIE CI_ Trade_ Product. Area Density. Measure Not UsedBBIE CI_ Trade_ Product. Colour. Code Not UsedBBIE CI_ Trade_ Product. Colour_ Description. Text Not UsedBBIE CI_ Trade_ Product. Use_ Description. Text Not UsedBBIE CI_ Trade_ Product. Designation. Text Not UsedBBIE CI_ Trade_ Product. End Item_ Name. Text Not UsedBBIE CI_ Trade_ Product. Latest_ Product Data Change. Date Time Not UsedBBIE CI_ Trade_ Product. End Item_ Type. Code Not UsedBBIE CI_ Trade_ Product. Variable Measure. Indicator Not UsedASBIE CI_ Trade_ Product. Applicable. CI_ Product_ CharacteristicASBIE CI_ Trade_ Product. Applicable. CI_ Material_ Goods Characteristic Not UsedASBIE CI_ Trade_ Product. Designated. CI_ Product_ Classification Not UsedASBIE CI_ Trade_ Product. Individual. CI_ Trade_ Product Instance Not UsedASBIE CI_ Trade_ Product. Certification Evidence_ Reference. CI_ Referenced_ Document Not UsedASBIE CI_ Trade_ Product. Inspection_ Reference. CI_ Referenced_ Document Not UsedASBIE CI_ Trade_ Product. Origin. CI_ Trade_ Country Not UsedASBIE CI_ Trade_ Product. Linear. CI_ Spatial_ Dimension Not UsedASBIE CI_ Trade_ Product. Minimum_ Linear. CI_ Spatial_ Dimension Not UsedASBIE CI_ Trade_ Product. Maximum_ Linear. CI_ Spatial_ Dimension Not UsedASBIE CI_ Trade_ Product. Manufacturer. CI_ Trade_ PartyASBIE CI_ Trade_ Product. MSDS_ Reference. CI_ Referenced_ Document Not UsedASBIE CI_ Trade_ Product. Additional_ Reference. CI_ Referenced_ DocumentASBIE CI_ Trade_ Product. Information. CI_ Note Not UsedASBIE CI_ Trade_ Product. Brand Owner. CI_ Trade_ Party Not UsedASBIE CI_ Trade_ Product. Legal Rights Owner. CI_ Trade_ Party Not UsedASBIE CI_ Trade_ Product. Presentation. Specified_ Binary File Not Used

RestrictionsABIE CI_ Trade_ Product. DetailsBBIE CI_ Trade_ Product. Global_ Identification. IdentifierBBIE CI_ Trade_ Product. Buyer Assigned_ Identification. IdentifierBBIE CI_ Trade_ Product. Manufacturer Assigned_ Identification. IdentifierBBIE CI_ Trade_ Product. Name. Text => Limited Occurrence (0..1)BBIE CI_ Trade_ Product. Description. TextBBIE CI_ Trade_ Product. Type. Code => Specific CodelistASBIE CI_ Trade_ Product. Applicable. CI_ Product_ CharacteristicASBIE CI_ Trade_ Product. Manufacturer. CI_ Trade_ PartyASBIE CI_ Trade_ Product. Additional_ Reference. CI_ Referenced_ Document

MBIEBIE

NDR

UN/CEFACT XSD Schema are derived from components created through the application of CCTS, UN/CEFACT Modelling Methodology (UMM) process modelling and data analysis, and Core Component Business Document Assembly (CCBDA).

The Core Component Business Document Assembly (CCBDA) specification provides a mechanism for restricting ABIEs in order to assemble a single message. Messages in an XML context correspond to a root schema, and as such, the restricted ABIEs would be declared in an internal schema. These ABIEs will be defined as xsd:complexType in an internal schema module rather than in the reusable ABIE schema module. UN/CEFACT XSD Schema may have zero or more internal schema modules.

A UN/CEFACT internal schema module will contain schema constructs representing ABIEs that are specific to a given root schema, such as restricted ABIEs created through CCBDA. Internal schema modules reside in the same namespace as their root schema.

CCBDA & NDR

REQ1. Clear rules for restrictions of MBIE.

REQ2. Rules for identification of MA and MBIE.

REQ3. Assembly rules for Internal Schema used for MBIEs.

REQ4. Rules for restricting code lists.

REQ5. Publication rules for MA.

REQ6. RSM template for MBIE.

REQ7. Review of CCBDA.

REQ8. Guidelines for Message Design Process

REQ9. Facets for MBIEs

2. Requirements List

14

REQ1. Clear rules for restrictions of MBIE.

1. Limited BBIEs and ASBIEs under the ABIE.2. Limited occurrence for BBIE or ASBIE.3. Additional qDT for the BBIE.4. Limited Context.5. Restricted scope of the description according to the above limitation.

The MBIE should have the new definition according to it’s restrictions.Use uDT instead of qDT defined in CCL.

1. Adding BBIEs and/or ASBIEs to the published ABIE.2. Expand occurrence for BBIE or ASBIE3. Remove existing qDT specified for BBIE.

Available restrictions

Not allowed

Issues

15

REQ2. Rules for identification of MA and MBIE.Do we need to uniquely identify the message artefacts, such as MBIE? The team agreed that this not is needed since they are unique within their context, i.e. the message. As long as they are duly noted in the RSM, using the new template, they are accessible and cannot be confused with other MBIEs. It is however important to note the UN id number for the ABIE from which it is derived.

Identification of MA:Recommend to add a qualifier to the UN specified message name.

There may be requirements to identify the deferent MBIEs derived from the same BIE.There may be deferent MABIEs (deferent restriction of ABIE) under the parent MABIE.There may be deferent MBBIEs (deferent qDT) under the parent MABIE .

Issues

16

REQ3. Assembly rules for Internal Schema used for MBIEs.The Core Component Business Document Assembly (CCBDA) specification provides a mechanism for restricting ABIEs in order to assemble a single message. Messages in an XML context correspond to a root schema, and as such, the restricted ABIEs would be declared in an internal schema. These ABIEs will be defined as xsd:complexType in an internal schema module rather than in the reusable ABIE schema module, (See Section 5.5.3.4 below). UN/CEFACT XSD Schema may have zero or more internal schema modules.

A UN/CEFACT internal schema module will contain schema constructs representing ABIEs that are specific to a given root schema, such as restricted ABIEs created through CCBDA. Internal schema modules reside in the same namespace as their root schema.

1. Can we specify the internal schema with using Reusable ABIE Modules ?Issues

17

REQ4. Rules for restricting code lists.

When a user community wishes to restrict the allowed code values expressed in an existing schema, a new qualified datatype will be created in the QDT schema module, a new restricted codelist schema module will be created, and a new xsd:simpleType will be defined. This new xsd:simpleType will contain a complete list of allowed enumerations.

1. Additional qDT (not specified in CCL) is allowed for MBIE ?2. How to manage the restricted codelist ?

Issues

Use the unqualified code data type with supplementary components as follows.Code List. IdentifierCode List. Agency. Identifier, Code List. Agency Name. TextCode List. Name. Text, Code List. Version. IdentifierCode. Name. Text, Language. IdentifierCode List. Uniform Resource. IdentifierCode List Scheme. Uniform Resource. Identifier

OR

18

REQ5. Publication rules for MA.1. Publication format for UN Standard message (MA)2. Do we need to publish the MA with restricted MBIE ?

19

REQ6. RSM template for MBIE.

The group reviewed the RSM template since the new version is not widely known and has only been applied by a couple of projects. The general finding is that it works and is helpful. Some minor correction will be needed:A new chapter ‘New and changed restrictions’ should be added in chapter 2.7. Compare chapter 2.6.2.1There is no mentioning of legal or footer information, such as copyright, dates etc. Anders to check with the UN SecretariatRules or guidelines when to restrict an ABIE vs a MBIE should be addedA review is needed to ensure that the terms ‘document’ and ‘message’ are used correctly and coherentlyThe acronyms CCDL and CCMA need to be aligned

REQ7. Review of CCBDA.Some errors and ambiguities in CCBDA may require an errata or new version.The reference to the Business Document Header, BDH, is using the new version that is not published and probably never will (at least not in its current form). Either we need to refer to the published version, SBDH, or make the descriptions more generic.Rules or guidelines when to restrict an ABIE vs a MBIE should be addedThe acronyms CCDL and CCMA need to be aligned.

20

REQ8. Guidelines for Message Design ProcessUse UN standard message as the template for MA.

Expand all the MBIEs into the message definition template using the underlining ABIEs in the reusable ABIE module.

REQ9. Facet for MBIEsHow to specify the facets for using MBIEs, such as the limitation of data element length.

New EDI Platform (Web API)

Generation of EDI in UN/CEFACT

Generation Syntax for Information Messaging Service

1st

Generation1985~

EDIFACTVAN Service providorX.25

2nd

Generation2000～

ebXMLInternetTCP/IP、SOAP

3rdGeneration2020~

JSON-LDCloud (Web API)RESTful

22

UN/CEFACT Standards for Web Developers

The rise of web platforms that exchange data via RESTful JSON APIs presents a new paradigm for B2B data exchange. But developers of web platforms rarely look to publishers like UN/CEFACT to guide the design of their APIs. The purpose of this project is make UN/CEFACT semantic standards accessible to web developers and to support interoperable implementations.

https://edi3.org

Scope of the standards and specifications•Semantic Specifications: The primary output of this site. A suite of Open API 3.0 interfacespecifications and JSON-LD semantic definitions to support consistent and interoperableimplementations of trade, transport, financial, and regulatory process APIs in the international supplychain.

•Technical Specifications: Cross-platform interoperability needs consistency at the technical layertoo. This suite of specifications does not re-invent existing technical standards but rather providesrules and patterns for consistent use of them. For example standard OAuth2.0 claims & scopes andstandard W3C WebSub event header metadata. We also provide a resource discovery mechanismbased on DNS that allows a find the API URL given a business identifier like a business number orcontainer number.

•Tools & Methods: A rather more specialist suite of specifications that are really only of interest ifyou are a modelling tool vendor or a contributor to the semantic specifications on this site (i.e. youare a user of conformant tools). These specifications help to ensure quality and consistency in thework of transforming established UN/CEFACT semantic models into the Open API and JSON-LDspecifications on this site.

Project 1: API Town Plan

A first draft API town plan : As a clickable map covering Trade, Transport, Regulatory, and Financial domains as well as agriculture, tourism and other domains.

A town plan governance framework : That defines how the town plan is managed and how new APIs are added.

Conformant API Implementations : At least two domains have each followed the RDM2API methodology and have published at least one API that aligns with the town plan.

Project 2: RDM to API Re-use our semantics: UN/CEFACT library content (RDM) can be imported into any conformant modelling tool or semantic tool.

Model consistently: API Resource / Event models and JSON-LD dictionaries can be created in any conformant modelling tool and easily mapped to the imported RDM definitions.

Publish specifications: API reference specifications (Including Open API3.0 and JSON-LD) can be generated from the modelling tool and published to open platforms such as Github.

Test conformance of their implementations. Actual API implementations can be tested against the reference specifications and a conformance report generated.