General

What does conformance to a Standard mean?

Conformance to a standard means that products, services or implementations that claim such, must satisfy 100% of all the mandatory ‘requirements’ found in the ‘normative’ sections.

For example, ISO/TS 15000-5:2005 and ISO 15000-5:2014 define conformance as:

Applications will be considered to be in full conformance with this technical specification if they comply with the content of normative sections, rules and definitions.

ISO/TS 15000-5:2005 defines in 4.2 that sections 6, 7, 8 and 9 are normative.

ISO 15000-5:2014 defines in 4.1 the set of rules that must be implemented in addition to the various normative sections and annexes.

Other ISO/TC 154 Standards, such as ISO 9735 and ISO 14533, contain conformance statements that are more complex because these standards are multi-part with normative references amongst these parts and/or reference other standards as normative that need to be conformed to as well.

What is ISO?

Not “what”, but “who”! Our standards are often highly technical – and they need to be – but they’re developed for people by people. So who we are is a network of the national standards institutes of some 163 countries, with a central office in Geneva, Switzerland, that coordinates the system and publishes the finished standards.

What does “international standardization” mean?

When the large majority of products or services in a particular business or industry sector conform to International Standards, a state of industry-wide standardization can be said to exist. This is achieved through consensus agreements between national delegations representing all the economic stakeholders concerned – suppliers, users and, often, governments. They agree on specifications and criteria to be applied consistently in the classification of materials, the manufacture of products and the provision of services. In this way, International Standards provide a reference framework, or a common technological language, between suppliers and their customers – which facilitates trade and the transfer of technology.

Can anyone join ISO?

Not as individuals or as enterprises – although both have a range of opportunities for taking part in ISO’s work, or in contributing to the development of standards through the ISO member in their country. Membership of ISO is open to national standards institutes or similar organizations most representative of standardization in their country (one member in each country). Full members each have one vote, whatever the size or strength of the economy of the country concerned. This means that they can all make their voices heard in the development of standards which are important to their country’s industry. ISO also has two categories of membership for countries with fewer resources. Although such members do not have a vote, they can remain up to date on standardization developments. Lists of the three categories of ISO members are available on ISO Online.

What is ISO’s relation to governments?

ISO is a non-governmental organization (NGO). Therefore, unlike the United Nations, the national members of ISO are not delegations of the governments of those countries. As far as those national members are concerned, some are wholly private sector in origin, others are private sector organizations but have a special mandate from their governments on matters related to standardization, while still others are part of the governmental framework of their countries. In addition, government experts often participate in ISO’s standards’ development work. So, while ISO is an NGO, it receives input from the public sector as it does from the private sector.

ISO 15000-5 (Core Component Specification)

Is UBL 2.1 in conformance with ISO/TS 15000-5:2005?

The questions was raised because of a statement on the UBL Home page, which states:

“UBL was the first published data format specification produced in full conformance with UN/CEFACT’s ebXML Core Components Technical Specification (CCTS) Version 2.01 – ISO TS/15000–5:2005.”

For a standard to claim full conformance it must satisfy 100% of all the mandatory ‘requirements’ found in the ‘normative’ sections.

ISO/TS 15000–5:2005 (and UN/CEFACT’s ebXML Core Components Technical Specification (CCTS) Version 2.01) both contain the same statements defining conformance as:

  • Applications will be considered to be in full conformance with this technical specification if they comply with the content of normative sections, rules and definitions.
  • Section 4.2 defines sections 6,7,8 and 9 as being normative.

The short answer is that UBL 2.1 is not in conformance with either version since it breaks at least one mandatory rule!

For the long answer, see the table below that list examples of requirements that are not met by UBL 2.1 to be in conformance:

ISO TS/15000–5:2005 Normative Rules OASIS UBL 2.1 Library Entries
[B3] A Basic Business Information Entity shall be based on a Basic Core Component Does not include any Basic Core Components
[B4] An Association Business Information Entity shall be based on an Association Core Components Does not include any Association Core Components
[B5] An Aggregate Business Information Entity shall be based on an Aggregate Core Component Does not include any Aggregate Core Components.
[B7] A Business Information Entity Property of an Aggregate Business Information Entity shall be based on a Core Component Property of the corresponding Aggregate Core Component Does not include any Aggregate Business Information Entities
[B8] The Data Type, on which a Basic Business Information Entity Property is based, shall itself be similar to the Data Type on which the corresponding Basic Core Component Property is based (i.e. it shall either be the same Data Type or a more restricted one) Does not include any Basic Core Component Properties
[B9] The Aggregate Business Information Entity, on which an Association Business Information Entity Property is based, shall itself be based on the Aggregate Core Component on which the corresponding Association Core Component Property is based Does not include any Aggregate Core Components or Association Core Components
[C1] Each Core Component Type, Basic Core Component, Association Core Component or Aggregate Core Component must have its own unique semantic definition within the library of which it is a part. The definition shall be developed first and the Dictionary Entry Name shall be extracted from it. Comments can be used to further clarify the definition, to provide examples and/or to reference a recognized standard There are no publicly published core components that allow this rule to be followed
[C18] The Dictionary Entry Name shall be concise and shall not contain consecutive redundant words Examples of entries not in conformance:

Address. Address Type Code. Code
Order Reference. Sales Order Identifier. Identifier
Tax Category. Per Unit_ Amount. Amount

 

What are the differences between ISO 15000-5 and OASIS’ UBL?

The table below shows on the left side the required parts defined within ISO 15000–5:2014. The right side shows the corresponding parts, if available, within OASIS’ UBL 2.0 and 2.1.

ISO 15000–5:2014 OASIS UBL 2.0 and 2.1
Syntax Neutral data model XML only (syntax specific)
Data model non-normative (optional)[1]
Can be used to create other syntax solutions Cannot be used to create other syntax solutions
Normative Categories of building blocks:[2] Current building blocks:
Basic Core Component (BCC)
Association Core Component (ASCC)
Aggregate Core Component (ACC)
Core Component Type (CCT) Core Component Type
(only basic definitions are provided)
Basic Business Information Entity (BBIE); UBL BBIEs
Association Business Information Entity (ASBIE) UBL ASBIEs
Aggregate Business Information Entity (ABIE) UBL ABIEs

 

Implementations are considered to be in full conformance with ISO 15000–5:2014 if they comply with the content of normative clauses, rules and definitions.[3]


  1. OASIS UBL 2.1 Specification, 2013 November, http://docs.oasis-open.org/ubl/os-UBL–2.1/UBL–2.1.html  ↩
  2. ISO 15000–5:2014, Section 4 and 5  ↩
  3. ISO 15000–5:2014, Section 6  ↩

ISO 9735 (EDIFACT Syntax)

Does UNOA as Syntax Identifier allow lowercase characters (a-z)?

The answer is for all versions of ISO 9735 a absolute NO !

Syntax data element 0001 (Syntax Identifier) is defined as:

Coded identification of the agency controlling the syntax, and of the character repertoire used in an interchange.

The definition for the UMOA code value within the code list of 0001 is:

As defined in the basic code table of ISO 646 with the exceptions of lower case letters, alternative graphic character allocations and national or application-oriented graphic character allocations.

To be in conformance with ISO 9735 any product, including message instances, must observe the restrictions and only use uppercase letters when using UNOA as the syntax identifier.

What are the differences amongst the various versions of ISO 9735?

Introduction

The EDIFACT Application Level Syntax Rules (ISO 9735) Level represent the rules at the application level for the structuring of data in the interchange of electronic messages in an open environment, based on the requirements of either batch or interactive processing. In particular these syntax rules serve to support the global UN/EDIFACT standard for EDI. The syntax rules include the definition of the service envelopes, service messages (latest version) and syntax constructs such as the default separator characters and rules for inclusion and exclusion.

Version 4, consisted originally of 9 parts, which was approved in October 1998. Release 1 of version 4, added part 10 in 2002.

Version 1

First published in 1988, this particular version no longer supports recent releases of the UN/EDIFACT directories. The directory version/release has changed from a numeric notation (eg. 91.2) to an alphanumeric format (eg. D.99B). In the UNG (Functional group header) and the UNH (Message header) service segments the corresponding data elements (0052/0054) are defined as being numeric.

Version 2

Version 2 is represented by Version 1 plus Corrigendum 1 published in 1990, the syntax rules specified in Version 2 remained unchanged from Version 1 with the exception that the alphanumeric version/release format is supported and the status of the message release number (0054) and controlling agency (0051) were changed from conditional to mandatory.

Version 3

Version 3 is represented by Version 2 plus Amendment 1, published in 1992. Amendment 1 extended the supported character sets from character set A (ISO 646 with the exception of lower case letters and certain graphic characters) and B (ISO 646 with the exception of certain graphic characters) to the character sets C through F (covering Latin, Cyrillic and Greek alphabets).

Version 4

Version 4 represents a significant revision to the syntax rules and supersedes the earlier publications. It is not fully upward compatible with Version 3 (eg. a single set of default service characters are defined in Version 4, where the level A and B character sets in earlier versions, each specified separate service characters).

While messages specified in the D.99A and earlier UN/EDIFACT Directories may use Versions 2, 3 and 4 of the syntax rules, it should be noted that messages specified in the D.99B and later UN/EDIFACT Directories that use features specific to Version 4 (eg. repeating composite data elements), these messages must use Version 4 of the syntax rules.

The Version 4 syntax rules comprise 10 individual parts:

  • Part 1: Syntax rules common to all parts, together with syntax service directories for each of the parts
  • Part 2: Syntax rules specific to batch EDI
  • Part 3: Syntax rules specific to interactive EDI
  • Part 4: Syntax and service report message for batch EDI (message type – CONTRL)
  • Part 5: Security rules for batch EDI (authenticity, integrity and non-repudiation of origin)
  • Part 6: Secure authentication and acknowledgement message (message type – AUTACK)
  • Part 7: Security rules for batch EDI (confidentiality)
  • Part 8: Associated data in EDI
  • Part 9: Security key and certificate management message (message type – KEYMAN)
  • Part 10: Syntax service directories

Part 1 is a re-draft of corresponding sections in the previous version of syntax rules. It consists of the rules common to all parts of Version 4 of the syntax, and includes the definitions and service directories for all parts. The basic syntax rules specified in this part remain unchanged from Version 3, with the exception that the coverage of character repertoires has been extended, and two new techniques have been introduced (the provision for ‘dependency notes’ and the introduction of a service repetition character, to support the capability of permitting multiple occurrences (repeats) of stand-alone and/or composite data elements). Both of these techniques are used in other parts of Version 4 of the syntax rules, and are available for specification in UN/EDIFACT messages that utilise these rules.

In addition, enhancements have been made to the batch interchange; group; and message header segments (UNB; UNG; and UNH).

Character repertoires: Because of the widening use of ISO 9735, it has become necessary to extend its coverage to include all character repertoires covered by ISO 8859, Parts 1-9 (Information processing – 8-Bit single – byte coded graphic character sets); the code extension techniques covered by ISO 2022 (with certain restrictions on its use within an interchange); and partial use of the techniques covered by ISO/IEC 10646-1.

Dependency notes: These provide a formal notation to express relationships within UN/EDIFACT message, segment and composite data element specifications.

Repeating data elements: The specification of multiple occurrences of a message within a group or within an interchange; a group within an interchange; and a segment group and/or a segment within a message, which existed in the previous version of the syntax rules, has been extended in the current version. The additional capability for the specification of multiple occurrences of a stand-alone data element and/or of a composite data element within a segment has been introduced.

UNB – Interchange header segment: This segment has been enhanced to permit the identification of the service code list directory version number; identification of the character encoding scheme; and internal sub-identification of the sender and recipient. In addition, to conform to year 2000 requirements, the date format in this segment has been extended.

UNG – Group header segment: This segment has been re-named and its function changed to permit one or more message types and/or packages to be contained in the group. As a result, certain data elements, which are now redundant, have been marked for deletion. In addition, to conform to year 2000 requirements, the date format in this segment has been extended.

UNH – Message header segment: This segment has been enhanced to permit the identification of a message subset, of a related message implementation guideline, and of a related scenario.

UGH/UGT – Anti-collision segment group: An addition has been made in this version of the syntax rules to permit the prevention of segment collision, by use of the UGH/UGT segment group. This technique may be used in a UN/EDIFACT message specification when it is not otherwise possible to ensure unambiguous identification of each message segment upon receipt.

Part 2 is specific to batch EDI and is a re-draft of corresponding sections in the previous version of the syntax rules. It is identical, except for minor changes to terminology, and for clarification of the use of segment groups.

Part 3 is a new part, which has been added to the syntax rules. It provides for the exchange of UN/EDIFACT messages in an interactive (conversational) EDI environment. Interactive EDI (I-EDI) is characterised by the following:

  • a formalised association between the two parties using a dialogue,
  • the ability, dynamically, to direct the course of the I-EDI transaction, depending upon the result of earlier exchanges within the dialogue,
  • short response times,
  • all the messages exchanged within one dialogue relate to the same business transaction,
  • a transaction is a controlled set of dialogues that can take place between two or more parties.

These characteristics differentiate I-EDI from batch EDI (as specified in Part 2). For consistency and in order to simplify the implementation of the syntax rules for those users who wish to utilise both batch and interactive processing, this part of the rules has been aligned as far as possible with the batch syntax rules.

Part 4 of the syntax rules provides the capability for the automatic preparation of the CONTRL message in response to a received interchange, group, message or package:

  • to acknowledge a correct syntactical structure; or
  • to reject an incorrect syntactical structure.

In the case of rejection, the message lists any syntactical errors or unsupported functions encountered. In addition to the above, the message may be used to indicate only the receipt of an interchange.

It is based upon a similar CONTRL service message developed and published as separate document for use with earlier versions of the syntax rules.

Part 5 is a new part, which has been added to the syntax rules. It provides an optional capability of securing batch UN/EDIFACT structures. It provides a method to address message/package level, group level, and interchange level security for authenticity, integrity and non-repudiation of origin, in accordance with established security mechanisms.

Part 6 is a new part, which has been added to the syntax rules. It provides an optional capability of securing batch UN/EDIFACT structures, ie. messages, packages, groups or interchanges, by means of a secure authentication and acknowledgement message, AUTACK.

Part 7 is a new part, which has been added to the syntax rules. It provides an optional capability of applying confidentiality to a batch UN/EDIFACT structures. It provides a method to address message/package level, group level and interchange level security for confidentiality in accordance with established security mechanisms.

Part 8 is a new part, which has been added to the syntax rules. It provides an optional capability of associating a package of data, which contains an object bounded by EDIFACT service segments as envelopes. The option permits the transfer within an UN/EDIFACT interchange of data which can be created by other applications, such as STEP (Standard for The Exchange of Product model data), CAD (Computer Aided Design), etc., and which cannot be carried by means of an UN/EDIFACT message.

Part 9 is a new part, which has been added to the syntax rules. It provides an optional capability of managing security keys and certificates using the KEYMAN message.

Part 10 was added with the publication of Release 1. For maintenance reasons of the Syntax service directories this part was extracted and updated from each of the relevant annex parts of the ISO 9735 series, first edition, published in 1998 and 1999.