Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Message Construction Guideline

other

Linktoparent

Project Details

Page properties
Domain
Project Identifier
Text Field
defaultexample: P1021
idpid
requiredtrue
P1076
Bureau Decision #
Text Field
defaultexample: P1021
idBureauDecision
requiredtrue
#TBD#1903058, #2003094; #2006001
Project Proposal Status

SP Page Status
dateMar 09, 2018 12:14
hidetrue
width25%
userMalik
statusofficial

Project Page

TBDMessage Construction Guideline Project

Supporting VC
Project Lead
HoD Support
Text Field
defaultexample: EU / US / UN
idHodSupport
requiredtrue
N/A
Status
Select2
defaultSelect the status for this project
idproject_status
requiredtrue
selectedIn developmentCompleted
  • Initiated
  • In development
  • Completed
Version
Text Field
defaultClick to set the version number
idversion_number
requiredtrue
23.0
Submitted date
Date Picker
defaultClick to set the submissions date
idsubmitted_date
requiredtrue
2019-05-03
Draft Development Completion
Date Picker
defaultDraft Development date
idDraft
20192020-1208-1830
Publication Date
Date Picker
defaultExit date
idExit
20122020-0411-1815

Project Purpose

Text Area
default<click here to edit>
idproject_purpose
For semantic interoperability in the field of Trade Facilitation and eBusiness, UN/CEFACT Technical Specifications and Dictionaries should be used more widely in the world.
There are several standard messages published in the UN/CEFACT library (Web site) which are designed to be used widely including general purpose business information entities and code lists.
The other hand, a user’s application used within a trading partner’s needs and can handle a part of information of the standard message. This causes frustration among users especially SMEs, such as;
	(1) It needs a large size standard message for the small set of information used in user’s application.
	(2) Each user application has to handle a bunch of information defined in the standard message.
	(3) A user cannot predict the usable set of information in the standard message received.
Fortunately, we have the technical specification Core Component Business Document Assembly (CCBDA) which enables defining a subset of the standard message particularly through a Reference-Data Model approach. This CCBDA specification has the capability to solve the above issues.
However, there seems to be some difficulties to apply CCBDA specification for implementing restricted messages while keeping interoperability, as follows.
	 No ful rules for restrictions of MBIE.
	 No rules for identifier of MA, MBIE.
	 No construction rules for internal schema used for MBIEs.
	 No rules for restricting code lists.
	 No publication rules for MA.
Further more,
	 Considering an updated RSM template describing MBIEs;
	 Considering an updated namespace for MBIEs;
	 Considering an updated relation with XHE (Exchange Header Envelope) specification;
It is desirable to take careful guidance for message implementations based on CCBDA specification to keep interoperability among EDI users.
This project introduces the guidelines how to define a Message Assembly (MA) constructed with Message Business Information Entities (MBIE) and Qualified Data Type (QDT).

Project Scope

Text Area
default<click here to edit>
idproject_scope
The guidelines introduce the method to design a XML user message using MA, MBIE and QDT under the rules of CCTS, CCBDA and NDR.

Project Deliverables

Text Area
default<click here to edit>
idproject_deliverables
The project deliverables are:
	• Deliverable 1: XML Message design guidelines for CCBDA
	• Deliverable 2: Publication guidelines for MA, MBIE, QDT
	• Deliverable 3: RSM guidelines for the message using MBIE and QDT
	• Deliverable 4: Requirements for amendment to related technical specifications, if any

Exit Criteria

Text Area
default<click here to edit>
idexit_criteria
The exit criteria will be:
	• Exit Criteria for Deliv. 1: The guidelines for XML message implementation based CCBDA approved by the Bureau.
	• Exit Criteria for Deliv. 2: Publication guidelines for MA, MBIE, QDT approved by the Bureau
	• Exit Criteria for Deliv. 3: RSM guidelines for the message using MBIE and QDT approved by the Bureau
	• Exit Criteria for Deliv. 4: List of project proposal(s) to amend related technical specifications recognized by the Bureau, if applicable

Project Team Membership and Required Functional Expertise

Text Area
default<click here to edit>
idproject_membership
Membership is open to UN/CEFACT experts with broad knowledge in the area of: XML message design and related activities
In addition, Heads of Delegations may invite technical experts from their constituency to participate in the work.
Experts are expected to contribute to the work based solely on their expertise and to comply with the UN/CEFACT Code of Conduct and Ethics and the policy on Intellectual Property Rights.

Geographical Focus

Text Area
default<click here to edit>
idgeographical_focus
The geographical focus of the project is global.

Initial Contributions

Text Area
default<click here to edit>
idinitial_contr
• Core Components Technical Specification – Part 8 of the ebXML Framework, Version 2.01
• Core Components Business Document Assembly Technical Specification, CCBDA, version 1.0
• UN/CEFACT XML Naming and Design Rules for CCTS 2.01 Version 2.1 dated 27 May 2014
• Requirements Specification Mapping (RSM) Documentation Template Guidelines Version 2.0

Resource Requirements

Text Area
default<click here to edit>
idresource_requirements
Establishing the necessary CUE pages for the project


Project Proposal Files

Attachments
oldfalse