Reference Model for Inclusion of Sender and Receiver Identification in XML

ASC X12 Standards for Electronic Data Interchange Technical Report Type 2
Reference Model for Inclusion of Sender and Receiver Identification in XML

JANUARY 2023

Copyright © 2017-2023, X12, Format © 2017-2023 Washington Publishing Company. Exclusively published by the Washington Publishing Company. No part of this publication may be distributed, posted, reproduced, stored in a retrieval system, or transmitted in any form or by any means without the prior written permission of the copyright owner.

Intellectual Property
X12 holds the copyright on the Standards and associated publications designed to facilitate implementation of the Standards. Users of all X12 publications should be aware of the permissible uses, as well as the limitations on such usage, as outlined here: store.x12.org/store/ip-use.

Preface

General

This document is a Technical Report Type 2 (TR2), commonly referred to as a Reference Model. It was developed by ASC X12C^[1], the Communications and Controls subcommittee.

This technical report was prepared under the guidance of the Accredited Standards Committee (ASC) on Electronic Data Interchange, X12. Organized under the procedures of the American National Standards Institute, ASC X12 was charged with the development of transactions and structures for use in an Electronic Data Interchange (EDI) environment.

ASC X12 has the following subcommittees:

ASC X12C Communications and Controls
ASC X12F Finance
ASC X12I Transportation
ASC X12J Technical Assessment
ASC X12M Supply Chain
ASC X12N Insurance

In developing TR2s, it is the aim of the ASC X12 subcommittees to facilitate the use and understanding of the standards and, in this case, certain aspects of X12 type 3 technical reports (TR3).

Version and Release

This Reference Model is not based on or dependent on any particular version of the X12 Standards referenced; information is useful for applications "...regardless of which version/release of the standards or the defining documents for the X12 syntax (X12.5 and X12.6) is being used."

Referenced and Related Standards

This standard is used with the ASC X12 series of standards on electronic data interchange.

The following material is from The Internet Engineering Task Force (IETF®). The mission of the IETF is to make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet.

The following verbatim text is from the cited document as noted immediately below.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

Key words for use in RFCs to Indicate Requirement Levels

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document:

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Note that the force of these words is modified by the requirement level of the document in which they are used.

MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.
MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification.
SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)

Comments

Comments, questions, and suggestions for improvement of this document may be submitted at changerequest@x12.org.

^[1] Within this technical report, "ASC X12" refers to Accredited Standards Committee X12 and its subcommittees. "X12" labels the standards and other work products of ASC X12.

Purpose and Scope

This technical report describes a methodology to construct Extensible Markup Language (XML) element names from ASC X12 Technical Report Type 3 (TR3) metadata for use in creating a processing instruction for envelope data schemas written in World Wide Web Consortium (W3C) XML Schema Definition Language (W3C XSD).

This TR2 is intended to serve these major purposes:

To specify what X12 metadata is used to form XSD processing instructions
To formally define metadata to be used in the XSD processing instructions
To specify how to construct the processing instructions conveying this metadata

Related X12 Standards and Technical Reports

X12.5 Application Control Structure
All ASC X12 Type 3 Technical Reports
Compliance in X12 Type 2 Technical Report
All other ASC X12 Technical Type 2 Reports

Introduction

The use of ASC X12 standards is voluntary, although government agencies may mandate their use. Further defining the standards and restricting options within the standards through implementation practices provides additional metadata that is useful in constructing meaningful XML processing instructions. The additional metadata is defined by X12, but not the aggregation of that metadata in a different syntax.

Metadata

Generic X12 Metadata

This specification uses the following X12 metadata defined in X12.5:

Section 4.4.1 – Basic Interchange Segments
Section 5.1.2 – Interchange Control Header Segment

TR3 Metadata

This specification uses the following TR3 metadata:

C – EDI Control Directory

Specification

The following specify metadata used to construct XML Processing Instructions. Referenced from 2.6 of the XML specification (refer to world wide web consortium (W3C) www.w3.org/TR/REC-xml for the complete spec):

Processing Instruction
Tag Name	ASC X12 Data Element Reference	X12 Data Type	X12 Min/Max Length	XML Example
asc-x12 format	GS08/ST01	AN	12	asc-x12 format="XML404"
sender-qualifier	ISA05	ID	2/2	sender-qualifier="ZZ"
sender	ISA06	AN	15/15	sender="CONPAP"
receiver-qualifier	ISA07	ID	2/2	receiver-qualifier="ZZ"
receiver	ISA08	AN	15/15	receiver="NS"
controlnumber	ISA13	N0	9/9	controlnumber="000004162"
standardversion	ISA	ID	5/5	version= "00701"
date	ISA09	DT	6/6	date="20170129"
time	ISA10	TM	4/4	time="1220"

<?asc-x12 format="XML404" sender-qualifier="ZZ" sender="CONPAP" receiver-qualifier= "ZZ" receiver="NS" controlnumber="000004162" version= "00701" date="20170129" time="1220"?>

Processing Instruction

Processing instructions (PIs) allow documents to contain instructions for applications. PIs are not part of the document's character data, but must be passed through to the application. The meaning of processing instructions are defined within trading partner agreements.

Usage

Implementers will define the usage of the XML processing instruction values. Not all values are required to be used.

The ASC X12 Data Elements, Data types and Min/Max Length have been included as reference only.

XML payloads are not required to conform to the ASC X12 data structures, XML may carry data that is not permitted in the EDI data stream. For example:

Date ="20170129" does not conform to ISA09, DT 6/6, in EDI the date must be "170129".