X12C Ad Hoc Task Group on the use of XML with X12 EDI
Preliminary Findings and Recommendations on the
Representation of X12 Data Elements and Structures in XML
Sponsored by
CommerceNet™ Consortium, ANSI ASC X12, and the XML/EDI
Group
Version 1.0
August 31, 1998
Editors:
Bob Crowley, Rik Drummond, and David Webber
Contributors:
Martin Bryan, Dan Codman, Betty Harvey, John Hathaway, Denis Hill, William Kammerer, John Kevlin,
Robert Miller, Peter Pruyne, Mike Rawlins
Preliminary Findings and Recommendations on XML-X12
Version 1.0
Table of Contents
Introduction ....................................................................................................... 4
1.
Document Status................................................................................................ 4
2.
Objectives ........................................................................................................... 4
3.
Rationale for Using X12 Semantics in XML/EDI............................................ 5
4.
The Vision of EDI Representations in XML .................................................... 5
5.
Environments for XML/EDI Usage .................................................................. 6
5.1.
XML Receivers ............................................................................................................. 6
5.2.
XML Senders ................................................................................................................ 7
5.3.
Environments ............................................................................................................... 7
6.
General Definitions ........................................................................................... 8
7.
Assumptions and Determinations ..................................................................... 9
7.1.
Additions to the X12 Code and Elements Dictionary ............................................... 9
7.2.
Alignment with Other Repository Type Efforts ........................................................ 9
8.
Data Element Name Generation from the X12 Syntax Databases .................. 9
9.
NameSpaces ..................................................................................................... 10
9.1.
NameSpaces Allow Redefinition of Data Elements ................................................. 10
9.2.
NameSpaces Allow References to External Code Lists .......................................... 10
10.
Open Issues at the Writing of this Draft ......................................................... 13
11.
Requirements ................................................................................................... 13
11.1.
The Basic Requirements ............................................................................................ 13
11.2.
Discussion on the Requirements ............................................................................... 14
12.
Loops, Loop Counts and Datatypes in XML ................................................. 15
13.
Implementing XML DTDs using X12 Unique IDs, Tag Names and PSDEs 15
13.1.
Understanding Tables 2a and 2b .............................................................................. 15
13.2.
Issues and Descriptions of Tables 2a and 2b ........................................................... 18
13.3.
Steps for Creating an X12/XML DTD from an XML DTD using
Tables 2a and 2b ....................................................................................................... 20
14.
XML Names Discussion .................................................................................. 21
14.1.
Unique ID Generation ............................................................................................... 21
14.2.
Human-readable XML Tag Generation .................................................................. 22
14.3.
Well-formed Purchase Order Example ................................................................... 24
14.4.
DTD Name Definition Example for a Purchase Order ........................................... 24
Page 2
Preliminary Findings and Recommendations on XML-X12
Version 1.0
15.
XML/EDI Semantics and the X12 868 Electronic Form Structure .............. 25
16.
Repositories and their Purpose ....................................................................... 26
17.
XML and Object Technology .......................................................................... 26
Appendix A — Full List of Requirements ...................................................................... 27
Appendix B — Partial List of Data Element Name Extensions .................................... 29
Appendix C — Example DTD Naming for an 850 Purchase Order ............................ 41
Appendix D — Scenario .................................................................................................. 44
Appendix E — Sample Programming for XML Interactions ........................................ 45
Appendix F — Example Use Case .................................................................................. 49
F.1. Describing the Scenario................................................................................................... 49
F.2. Step 1 — The Output from the E-Commerce System is Received in XML Format .. 51
F.3. Step 2 — Additional Information is Now Required for EDI Compliance .................. 51
F.4. Step 3 — The Delivery Phase .......................................................................................... 51
Page 3
Preliminary Findings and Recommendations on XML-X12
Version 1.0
Introduction
The purpose of this document is to make a recommendation on the direction of the Joint
CommerceNet™ - ANSI ASC X12 - XML/EDI Group Ad Hoc Task Group on XML as a
basis for continuing formal work on the use of XML by X12 itself.
Included in this document are algorithms that can be used to generate XML segment
names and data element names from the existing X12 syntax tables. Because many
people reading this document will not have ready access to the X12 tables, the algorithms
are shown by example. Additionally, an example of a generated Document Type
Definition (DTD) is given in Appendix C to show what a generated XML DTD for a
Purchase Order would look like.
The further intent is to publish these results for general comment. Publishing these results
will allow XML developers to give us feedback suggesting further enhancements to the
specification. The results from the use of these names and structures in the broader XML
domain can then be considered in the subsequent formal work within ANSI
Subcommittee X12C.
1. Document Status
This document is a joint effort produced by the three sponsoring organizations, but is not
binding on any or all. Following this initial ad hoc effort, both ANSI Subcommittee
X12C and CommercNet™ are planning to initiate formal working groups to further
develop XML and X12. Each of these organizations has specific approval processes that
must be followed.
The X12 community is a major contributor to the document. However, this draft should
not be construed to be a formal X12 recommendation at this time. The final status of this
effort has yet to be determined within X12 itself.
This document will be used by CommerceNet™, the XML/EDI Group and others to
promote the use of XML/EDI to the XML electronic commerce developer community.
Other EDI organizations are also free to review and apply the techniques and ideas
expressed in this document.
2. Objectives
The broad objectives of this Ad Hoc Task Group include the following:

move the X12 EDI data dictionary and structures into XML in a manner that
retains the one-to-one semantic mapping between the X12 and XML data
elements

construct XML data element names in a manner that allows X12 electronic
commerce experts to use their process acumen in XML/EDI

support both the application-to-application and human-to-application interface
requirements
Page 4
Preliminary Findings and Recommendations on XML-X12
Version 1.0
3. Rationale for Using X12 Semantics in XML/EDI
XML (eXtensible Markup Language) may be the means to bridge EDI into Internet
Electronic Commerce (EC) by making the existing EDI knowledge base more readily
usable to the Internet EC developers.
In order to take advantage of the Internet’s speed, convenience and global user base, the
EDI community is investigating how to map X12 data elements, segments and
transaction structures into XML. The process has been divided into two phases.

Phase 1 — This paper is focused on the first set of basic XML syntax deliverables.
These include such items as datatypes syntax, XML/EDI DTDs, Loop definition
syntax and XML/EDI structures.

Phase 2 — Phase 2 will extend Phase 1 by recommending XML features for use in
the EDI arena such as XSL (the style sheet language for XML), NameSpace
definitions, and XML based definition repositories. Phase 2 will begin at the
completion of the Phase 1 effort.
XML/EDI is being developed based on the expectation that many application software
vendors will soon incorporate within their products the abilities to generate and process
XML.
4. The Vision of EDI Representations in XML
In X12, an instance of a transaction, such as a purchase order to ABC Tools, contains
data to be interpreted by a translator program. The translator program knows the proper
syntax and semantics of the data. Because the X12 syntax and data are specifically
designed to be read by machine, it can be difficult for humans to interpret transaction data
without either the transaction table text documents or a translator application to show the
semantic and syntactical meaning. XML offers a mechanism that allows data to be
transmitted with human-readable semantics that we believe will facilitate use in
application integration for Small and Medium Enterprises (SMEs). If SMEs receive data
in a format that shows the meaning of the data, this should make it easier for them to
integrate and understand the contents.
For example, in an X12 transaction instance, the discount price, such as *9.99*, would be
represented at a predetermined place in the transaction. The same transaction instance, in
XML, would show the discount price as <DiscountPrice>9.99</DiscountPrice>, making
the data more understandable to the end user. Additionally, if these pre-existing X12
business semantics are transferred into XML, then electronic commerce developers will
not need to define semantics unique to their applications. They will be able to use welldefined terms that are already heavily used across the business community. This use of a
common semantic will facilitate the flow of data across new innovative EC applications
because this common semantic is already used in well-defined processes that are
supported by existing X12 semantics. The use of the common semantic will facilitate the
integration of applications because data may be readily moved between like data
elements in each application and may require very little conversion or human intervention
to determine the source and destination of the data being moved.
Page 5
Preliminary Findings and Recommendations on XML-X12
Version 1.0
5. Environments for XML/EDI Usage
We envision many business scenarios for the use of XML linked to X12. Primarily these
scenarios involve Internet-based systems in organizations that are looking to link the
synergy of three functions:

delivery of XML formatted messages using HTTP and SMTP protocols and other
products via the Internet or proprietary means

direct integration of EDI-based processes with desktop software tools such as Web
browsers and office suite products such as spreadsheets, word processors, form flow
products, and business application databases

ability to provide formal business process underpinning (based on existing EDI
transactions) to Internet commerce environments
The direct corresponding business benefits of these are for those organizations to:

develop one set of document and transaction formats that will work with a broad
range of applications, resulting in cost savings in development, deployment and
maintenance of EDI-related software

take advantage of twenty years of process development knowledge represented in the
existing EDI processes, providing the ability for a broader business audience to
integrate with existing EDI implementations

take advantage of cheap, widely available communications systems and products,
with the ability to immediately take advantage of enhancements and innovations to
mainstream technologies (additionally, the direct support for complex compound
objects is built-in, including multi-lingual documents, non-ASCII content and process
objects)
The rest of this section describes in broad terms the primary users and environments for
which this X12-based XML/EDI solution is targeted. The requirements for
implementation conventions and standard XML DTDs are also discussed. Where
expected implementations are mentioned, we expect that the dominant trading partner
will dictate the implementation in much the same way that X12 hub-and-spoke
implementations operate.
In all cases, the solution is targeted primarily toward the transmission of a complete
business transaction (a document or, in X12 terms, a transaction set). The tagging
mechanisms may be used to tag individual fields on, for example, a human-readable Web
form, but this is not a prime consideration.
5.1.
XML Receivers
Receivers of XML/EDI fall into three basic classes:

Native XML processors — Business applications that import and process XML
directly. Standard DTDs are desirable (although not required), and the document must
conform to the receiver’s expected implementation.
Page 6
Preliminary Findings and Recommendations on XML-X12
Version 1.0

XML to application file — Business applications that do not process XML directly.
XML is translated by an external utility into an application format file, which is
imported into the application. Standard DTDs are desirable (although not required),
and the document must conform to the receiver’s expected implementation.

XML to browser — an XML document that is read by human using a Web browser,
word processor, or other generic XML reader. Data may be transferred to XML
supporting applications by “drag and drop.” Standardized tags are required. Standard
DTDs may be desirable, although not required.
5.2.
XML Senders
Senders of XML/EDI fall into three basic classes:

Native XML senders — Business applications that export XML directly. Standard
DTDs are desirable (although not required), and the document must conform to the
receiver’s expected implementation.

Application file to XML — Business applications that do not create XML directly.
Application format files, exported from the application, are translated by an external
utility into XML. Standard DTDs are desirable (although not required), and the
document must conform to the receiver’s expected implementation.

Browser to XML — XML documents that are generated from an XML form, from
human input using a Web browser, word processor, or other generic XML producer.
Data may be transferred from XML supporting applications by “drag and drop.”
Standardized tags are required. Standard DTDs may be desirable, although not
required.
5.3.
Environments
Listed below are the primary combinations of XML/EDI and X12 that we expect to see
implemented. This list is not exhaustive.

XML/EDI to XML/EDI — Sender generates XML/EDI directly from business
application, and receiver processes directly into their application. No human
intervention is necessary on either end. Standard DTDs are desirable (although not
required), and the document must conform to the receiver’s expected implementation.

XML/EDI to Browser, or Browser to XML/EDI — XML/EDI is generated or read by
application, and read or generated by a browser on the other end. Standard DTDs are
desirable (although not required), and the document must conform to the receiver’s
expected implementation when the receiving application imports it directly.

Application File to X12 or XML/EDI — Sender’s business application generates an
extract file, which is then processed by a translator. X12 or XML/EDI is generated,
depending on trading partner’s preference. This scenario is anticipated for current
large X12 users that may wish to generate XML/EDI for smaller partners that are not
X12 capable. The need for standard DTDs and implementations are as described
above for the basic classes of XML/EDI receivers.
Page 7
Preliminary Findings and Recommendations on XML-X12
Version 1.0

X12 or XML/EDI to Application File — Sender generates X12 or XML/EDI
dependent on capabilities. Input is processed by receiver’s translator into application
file format for import into application. This scenario is anticipated for current large
X12 users that may wish to receive XML/EDI from smaller partners that are not X12
capable. XML/EDI implementation must conform to receiver’s expectations.

X12 to XML/EDI, or XML/EDI to X12 by VAN or service bureau — A third party
provides translation between formats. Translation to X12 must conform to X12
version/release and implementation conventions, and translation to XML/EDI must
conform to XML receiver’s expectations as described above.
6. General Definitions

Data Element is used in this report in the same way “data element” is used in the X12
Data Element Dictionaries (more details are available from the DISA Web site
http://www.disa.org ). Note: An example would be “price,” which may be used in
multiple transaction sets and segments, and has a different meaning within each
context.

PSDE, Process-Segment-Data-Element, shows the data element in relationship to its
transaction set (process) and its segment. For example, the data element “price” that
occurs in an invoice is different from that in a purchase order. In X12, “price” is
called a data element and may be used in multiple transaction sets. However, for
mapping purposes we need to know more than just the data element number or name.
We also need to know to which transaction set it belongs, to which segment it belongs
and its position within the segment. That is why we have named the PSDE to signify
a data element within its transaction set (process) and segment context.

Transaction set is used in the same manner as the transaction set in the X12
definitions. Examples are purchase orders, loan approvals, invoices and remittance
advice.

Segment is used in the same manner as is defined in the X12 definitions. An X12
segment is analogous to a variable length record in other disciplines.

XML tag or tag is the name of an XML data element. The tag for the value “price”
could be “<price>.”
Example <price>9.99</price> or <price qual=“US”>9.99</price>

Process for our purposes is interchangeable with the transaction set names. The PO
transaction set is part of the purchase order process, the invoice is part of the invoice
process, and the loan approval transaction set is part of the loan approval process. We
assume that the transaction sets are each part of a process and contain data elements
and segment grouping appropriate for the process. We believe that the transaction set
places the element in a well-defined process.
Page 8
Preliminary Findings and Recommendations on XML-X12
Version 1.0
7. Assumptions and Determinations
7.1.
Additions to the X12 Code and Elements Dictionary
In order to map between an XML formatted document and the X12 code and element
standards, we must provide each X12 element with a Unique ID. We can assign a Unique
ID one time automatically with a simple numbering scheme for release 4010 of the X12
standard. Henceforth, any new elements will simply be assigned the next number in
sequence, as necessary.
7.2.
Alignment with Other Repository Type Efforts
One of the major considerations in this effort was to allow XML data elements to be
mapped to other data element naming or repository type efforts. Repositories use the
concept of a taxonomy labeling system that derives a unique label for each element
within their repositories (rather like the familiar Dewey Decimal system in book
libraries). Those data elements can be cross-referenced to other standards by using that
taxonomy label (in XML/EDI’s case the Unique ID).
Deriving a taxonomy scheme for X12 was considered both beyond the scope of this
ad hoc effort and beyond the resources available (it would be too time consuming to
implement). Instead, by generating a simple sequential Unique ID sequence for the X12
codes and elements, the limited objective of being able to directly identify them is
achieved. This then allows support for future mapping to repository standards. Example
tables (see Tables 2a and 2b and the worked example in Section 13.3) are provided to
illustrate how such one-to-one associations are implemented.
In addition to assigning a Unique ID, each element also has been assigned a preferred
human-readable and machine-processable XML tag name (hereafter called simply XML
tag name), based on its original name and data element semantic notes in the X12
element dictionary.
Then, to complete the associations to X12, a PSDE positional use descriptor is also
provided. This descriptor defines where, within a transaction set, the element occurs.
In summary, there are three identifiers:

a Unique ID — a simple character sequence that identifies the particular X12 element

a derived XML tag name — a human-readable name describing the element

a PSDE positional use descriptor — associates the element to its use within X12
transaction set(s). (Note: See definition of a PSDE, Process-Segment-Data-Element
in Section 6 above and see Appendix B.)
8. Data Element Name Generation from the X12 Syntax Databases
The key deliverable from this effort is to define X12 EDI data element names and
structures in XML. These names should convey as much information to the human user
as possible and yet retain the alignment with the existing X12 standards.
X12 is continually defining new data elements and modifying existing structures as they
identify additional needs. It is very important that we develop algorithms that allow us to
Page 9
Preliminary Findings and Recommendations on XML-X12
Version 1.0
read the X12 syntax and semantic tables and generate appropriate, well-formed XML
documents, DTDs and data element names across extensions to versions.
The algorithms, if constructed appropriately, could be used to generate XML/EDI from
the X12 syntax and semantic tables for each new version.
This document aims to show a limited number of instructive use case examples. The
primary focus has been a portion of a purchase order in XML format and its DTD using
the anticipated algorithms. This purchase order portion can be found in Section 14, and a
DTD example can be found in Appendix C.
9. NameSpaces
9.1.
NameSpaces Allow Redefinition of Data Elements
This document is a recommendation for naming XML data elements, segments and
transaction sets from the X12 Standard Version — Release 4010. It has been determined
that data element names and segments are extremely stable across versions. Most version
changes either add values to existing elements or create new elements. Therefore, XML
names and Unique IDs will not differ across versions of X12 for the same data element.
They can be expected to remain constant once determined.
However, the use of the XML NameSpace recommendations allow XML to
accommodate redefinition where required. The same NameSpace can be set to have
context-specific, and therefore version-specific, meanings. This technique will ensure that
we do not have collisions of Unique IDs and names over releases and versions. This area
requires further discussion because the area of NameSpaces is an evolving specification
within the W3C (World Wide Web Consortium) XML specification work itself. (More
information about W3C is available at http://www.w3c.org)
9.2.
NameSpaces Allow References to External Code Lists
An additional use for NameSpaces is to provide the means to express in shorthand
notation a reference to an extended list of allowed values for an X12 element.
Various X12 elements refer to code lists. Some codes are defined by X12 itself and are
included as part of the X12 standard. Yet others refer to external code lists maintained by
other authorities, such as the ISO or other organizations.
For example, X12 Data Element128, the Reference Identification Qualifier, used most
commonly in the REF segment, has over 1500 alphanumeric codes defined in ASC X12
004010. Each code has an associated free-form English description, with an
accompanying free-form explanation. For example, code value CT has the definition
“Contract Number” and no explanation (because the definition is self-explanatory); code
value IRN has the definition “Importer’s Reference Number to Letter of Credit,” but in
addition has an explanation that reads: “Letter of credit reference number issued by
buyer; cross-references the bank’s letter of credit number, once assigned.”
Each revision of the Draft Standard may result in new codes added, others deleted, and
still others whose definitions or explanations change. In general, the value of a coded ID
element must be one of the list provided by X12.
Page 10
Preliminary Findings and Recommendations on XML-X12
Version 1.0
Yet other data elements refer to “external code sources.” X12 Data Element 100, the
Currency Code, is expected to contain one of the values defined in ISO 4217. ISO 4217 is
a list of 3-character currency codes, along with the English names of the currency.
Validity of data values used in X12 Data Element 100 is a little looser than those defined
in coded ID elements whose values have been ordained by X12, because currency codes
may change independent of the X12 standard being used. For example, the currency of
Argentina changes every few years depending on inflation. When inflation rises too high,
they change the name and drop a couple of zeroes. On the other hand, countries (and their
currencies) go away, such as the German Democratic Republic and its DDR Mark. The
ISO periodically updates the list, and hence the year suffix in “ISO 4217-1996.”
An XML/X12 transaction/message needs to be self-contained and self-describing to the
point where the code sources will be provided in a machine-readable file or in a reference
to a location that contains such information. (It is anticipated that an authority will
provide the list in a machine-readable format that can be accessed by URL.) For
example, if we want to allow any of the D.E. 355 Unit of Measurement codes to be used,
we assume that the data creator will refer to the X12 book for acceptable code values.
Maybe we wish to restrict the currency code values to be used. Perhaps, for example, we
only use NAFTA country currencies, in which case we want to pare down ISO 4217 to
just “USD,” “CAD” and “MXP.” We assume that an authority provides the full ISO
4217 list as a URL reference. NameSpaces would then allow reference to a subset so only
those NAFTA currencies can be specified in XML EDI data.
Page 11
Preliminary Findings and Recommendations on XML-X12
Version 1.0
The following shows a possible means of using XML markup language to list code
values.
<code-list>
<desc>
<self>http://foresight-edi.com/rsrclnks/ISO_4217.xml</self>
<date>Apr 09,1998</date>
<time>08:00</time>
<source>ISO 4217</source>
<title>3 Character Country Codes</title>
<usage>ASC X12 D.E. 100 - Currency Code</usage>
<author>FORESIGHT Corp.</author>
</desc>
<codes>
<code><name>ADP</name><defn>Andorran Peseta</defn></code>
<code><name>AED</name><defn>United Arab Emirates Dirham</defn></code>
<code><name>AFA</name><defn>Afghanistan Afghani</defn></code>
<code><name>ALL</name><defn>Albanian Lek</defn></code>
<code><name>ANG</name><defn>Netherlands Antillian Guilder</defn></code>
<code><name>AOK</name><defn>Angolan Kwanza</defn></code>
<code><name>ARA</name><defn>Argentinian Austral</defn></code>
<code><name>ATS</name><defn>Austrian Schilling</defn></code>
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
<code><name>WST</name><defn>Samoan Tala</defn></code>
<code><name>YDD</name><defn>Democratic Yemeni Dinar</defn></code>
<code><name>YER</name><defn>Yemeni Rial</defn></code>
<code><name>YUD</name><defn>New Yugoslavia Dinar</defn></code>
<code><name>ZAR</name><defn>South African Rand</defn></code>
<code><name>ZMK</name><defn>Zambian Kwacha</defn></code>
<code><name>ZRZ</name><defn>Zaire Zaire</defn></code>
<code><name>ZWD</name><defn>Zimbabwe Dollar</defn></code>
</codes>
</code-list>
Page 12
Preliminary Findings and Recommendations on XML-X12
Version 1.0
10. Open Issues at the Writing of this Draft
Issues not fully addressed in this Phase 1 paper include:

At this stage, we have addressed the X12 loop within the DTD. However, it is
not visible in the document instance. Does a loop need to be represented in a
document instance to insure clarity for a human interpreter?

XML does not currently support datatyping, which would indicate the type of
data such as: numeric, alpha, real, etc. Because of this we have chosen to
implement datatyping in a later phase. We could implement basic datatypes right
now by following standard conventions, and then do more sophisticated
implementation in Phase 2. (See Section 12.)

Encryption, signature and signed receipt have not been implemented at this time.
There are various existing means to implement security such as: X12.58 or
S/MIME. They are left for a later phase. These issues are being addressed by the
XML development community with efforts such as RDF (Resource Description
Framework). Because of the evolving nature, these aspects might be better
reviewed in Phase 2.

XML NameSpaces, for alleviating confusion across X12 versions, have not been
implemented. The XML NameSpace mechanism has obvious use, but exact
details have not been fully determined, and the XML NameSpace specification is
deemed by many to be immature for our use at this time.
11. Requirements
11.1.
The Basic Requirements
The workgroup conducted a straw vote to identify the top requirements for this effort.
Those below received the most votes and form our high level guiding requirements. The
list of all items in the vote is included in Appendix A.
1. Each data element should have an assigned identifier (Unique ID), such as X2857,
and should support various aliases.
2. We must define the data element names and XML hierarchy in a manner that
facilitates mapping between X12 and other standards.
3. We must name data elements in a manner that will reflect their relation to the X12
transaction and context. We need to take advantage of nesting in XML to
represent hierarchical data.
4. The proposed XML/EDI architecture should accommodate business-system-tobusiness-system and computer-to-human requirements.
5. It is more important that we really use the XML/EDI capabilities than it is to
make XML/EDI completely backward compatible to X12.
6. It is important that we retain as much information as possible about data elements,
by naming them clearly from the X12 data element names, so that content experts
Page 13
Preliminary Findings and Recommendations on XML-X12
Version 1.0
can use existing expertise in mapping data elements between applications, EDI
and XML/EDI.
11.2.
Discussion on the Requirements
1. Each data element should have an assigned identifier such as X2857 and should
support various aliases.
Discussion: Our current thought is that a data element will have a Unique ID such as
x2857. Such an identifier will not explicitly indicate any X12 EDI transaction-related
structural information. A separate method will be used to determine relations between
elements, such as those methods detailed in Table 2a (discussed in Section 13).
2. We must define the data element names in a manner that facilitates mapping between
X12 and other standards.
Discussion: After reviewing repository efforts, the one thing in common that slows their
implementation is the need for content experts to be involved in taxonomy identifiers. In
this particular effort, we have finessed this issue by manually deriving names based on
the X12 names, and arbitrarily assigning unique identifiers (see 1 above) independent of
the taxonomy.
3. We need to take advantage of nesting in XML to represent hierarchical data.
Discussion: All data element names only have meaning when shown in light of their
position within the X12 transaction set, segment and segment position hierarchy. Our
data element naming scheme reflects the position of the data element within the nesting
hierarchy.
4. The proposed XML/EDI architecture should accommodate business-system-tobusiness-system and computer-to-human requirements.
Discussion: One of the things that XML will allow us to do is support the system-tosystem, human-to-human and human-to-system interfaces in a straightforward manner,
without a lot of conversion, or in the case of a human, the need for a translator. Business
processes that have human and application components could handle the data without a
lot of conversion back and forth. The XML/EDI structure should reflect the semantic
meaning of the data elements if possible.
5. It is more important that we really use the XML/EDI capabilities than it is to make it
completely backward compatible to X12.
Discussion: XML is a very powerful language that will grow with time. Some of the
outstanding XML/EDI issues will not allow XML/EDI to be completely backward
compatible to X12 at this time. It should be in the future when loop repeat counts and
some of the unusual data element dependencies are solved with new XML syntax. The
normal data element dependencies, such as “if and only if a1, then a2,” are easily handled
when the elements are adjacent. However, when they are not adjacent, it is much harder,
although possible, to show the dependencies between them. The initial versions of this
specification will not attempt to handle these elements. Another thing missing from the
XML specification is datatyping. Datatyping tells the number of characters and the type,
Page 14
Preliminary Findings and Recommendations on XML-X12
Version 1.0
such as alphanumeric or numeric only. Although this is not part of the XML Version 1
specification, it can be easily overcome with standard XML extensions.
6. It is important that we retain as much information as possible about data elements, by
naming them clearly from the X12 data element names, so that content experts can
use existing expertise in mapping data elements between applications, EDI and
XML/EDI.
Discussion: If we hope to have the XML EDI representations take off in a straightforward
manner, it is important that content experts in the purchase process or the inventory
process can easily transfer their knowledge base to the XML data element names. This
means that whatever they are named, they must clearly convey their existing EDI
meaning so that the content experts can offer direct assistance in the XML EC area.
12. Loops, Loop Counts and Datatypes in XML
Loops indicate two things: 1) a block of related segments that should occur together to
have meaning and 2) the number of times the block may be repeated within the
transaction. XML can easily indicate a block of related data with parentheses. The block
counts are another issue. Their resolution, if indicated, is left for a later phase.
Similarly, the current datatyping in XML is very similar to simple X12 transactions in
that all items are treated as strings. Only the application logic makes reference to the
definition as a DATE, or NUMERIC type with the appropriate picture format mask.
However, XML DTDs do provide the means to explicitly label elements with their exact
datatyping in the longer term. Because datatyping is an area that the W3C is still
developing within the XML specification, we will defer discussing the exact use of this
feature until Phase 2.
13. Implementing XML DTDs using X12 Unique IDs, Tag Names and PSDEs
13.1.
Understanding Tables 2a and 2b
The tables below show the items identified to date and the possible means of expressing
them to provide naming of code and element items from X12 into XML. The objective is
to provide a means to automatically reference or suggest suitable XML tag names
wherever possible.
However, we can accommodate developers in situations where they prefer to use existing
or alternate tag names. The XML DTD then contains the link between the locally defined
XML tag names and the X12 standard by assigning an ATTRIBUTE in the XML DTD of
something like “UID Value=X12345.” If the ATTRIBUTE is not defined, then the tag
name must match an existing X12 XML tag name; otherwise it will be skipped and
ignored. A simple mapping using the UID is then possible between the locally preferred
tag name and the actual X12 tag name using a direct lookup.
The mechanisms described provide a mapping that is independent and neutral of any
specific representation. The XML tag names, X12 Unique Identifier and PSDE usage
examples derived as described and listed in Appendix B are particularly suitable for this
schema.
Page 15
Preliminary Findings and Recommendations on XML-X12
Version 1.0
Table 1 — Explanation of Table 2a and 2b
Definition in Table 2a/b below
X12 XML Equivalent (Appendix B)
Valid Context or Pairing - usage codes
USAGE (PSDE)
Short XML Tag Name
DESCRIPTION / NEW XML TAG
NAME
XML Unique element ID
Not used, X12 specific only
Application Long Name
Unique ID (assigned for all X12 elements)
DE Number
Full description from X12 Implementation
Guidelines
Details from X12 Implementation Guidelines
where applicable
From X12 type definition
EDIFACT alignment element reference
Definition of Data Element (Semantics/
Description)
Applicable Data Type
Central Repository Cross Ref ID (optional)
Page 16
Preliminary Findings and Recommendations on XML-X12
Version 1.0
Table 2a — X12 XML Name Mapping
XML
Unique
Element
ID
Central
Applicable
Repository Data Type
Cross Ref ID
(Optional)
Language XML Tag
Code
Name
(ISO 639)
Generated
reference
code,
(must be a
valid
XML
nametype)
Example:
IDs from
other
standards
such as HL7
healthcare.
ISO ID
for
language1
Char,
Num,
Memo,
Logical,
Binary
AAA001
Char
En
AAA002
Char
En
XAB001
Numeric
En
UAA001
Char
Fr
Short
Name to
be used
in actual
XML
markup
Application
Long Name
Definition of Data
Element (Semantics/
Description)
May be same Free form memo field
as XML Tag
Name, or may
be longer unabbreviated
or reference
name
As shown below, the PSDE codes go in the column labeled “Valid Context or Pairing” in
2b, and the names in the “XML Tag Name” column in 2a, and the identifier in the main
first column “XML Unique Element ID.”
Additional columns such “Applicable Data Type” in 2a can then be populated as needed
from the existing X12 code and element dictionary.
Compound names can also be constructed for use in transaction sets. Provision is made to
support more than just X12 codes and elements by providing the ability to support other
EDI and multi-lingual implementations. This provision is in line with ultimately
developing a common format that is not just specific to X12.
The first table (2a) shows the XML specification with its Unique Reference ID, and the
second table (2b) shows the X12 equivalence including the message and segment
relationship.
This discussion is intended to be a starting point, more so for the continuing Phase 2
effort as noted in Section 3.
Page 17
Preliminary Findings and Recommendations on XML-X12
Version 1.0
Table 2b — X12 XML Name Mapping continued
XML
Unique
Element
ID
Generated
reference
code,
(must be a
valid XML
nametype)
Repository
Body
Central
Repository
Cross Ref ID
(Optional)
Example:
IDs from
other
standards
such as HL7
healthcare.
Valid Context
or Pairing
Purpose
Transaction ‘Segment,’
reference or ‘Loop,’
structure
‘Element’
component
of allowed
use.
Repository Tag
Name
AAA001
‘X12,’
‘UNE,’
‘HL7,’
‘FIX,’
‘OFX,’
‘OTP,’
and
so on
X12
AAA002
X12
X12Address Segment
N1.
XAB001
X12
Any
Element
Order.Date
UAA001
UNE
Any
Element
Nom
X850
For example, X12
XML tag name
Transaction X850:
X12
X12
X12
X12
13.2.
Issues and Descriptions of Tables 2a and 2b
13.2.1. XML Unique Element ID (Table 2a and 2b)
This column uses a generic encoding that can be automatically generated for all X12
elements. This ID must generate a valid XML name that starts with a letter.
13.2.2. Central Repository Cross Reference ID (Optional) (Table 2a and 2b)
This column includes a matching formal ID. The reference must be prefixed by a letter,
such as ‘U,’ to ensure a valid XML name. A taxonomy-independent identifier should be
considered because there are multiple taxonomies. Formal taxonomy naming schemes
require manual generation, so this is an impediment. Where formal taxonomies are
already available, however, they can be associated. Alternatively, this column provides a
placeholder for a more formal effort in the future to derive explicit taxonomy-based
labels.
The EDIFACT alignment effort has identified many common names and elements.
Where applicable, these can be added in this column. This column also provides means to
link to related standards other than just EDIFACT, i.e., HL7 healthcare, financial EDI
and so on.
Page 18
Preliminary Findings and Recommendations on XML-X12
Version 1.0
13.2.3. Applicable Data Type (Table 2a)
This column holds the type (such as DATE); this type should work across all uses and
formats. We need a set of unique representation classes that cover known types from X12
code and element dictionaries (amount, date, number, quantity, and so on). We also need
references to actual associated ATTRIBUTES to be held on each element too for
validating the DTD (these define the physical implementation of the representation class
— character, numeric, Boolean, binary, and so on).
13.2.4. Language Code (Table 2a)
This column should include the ISO 3166 codes for each language.
13.2.5. XML Tag Name (i.e., as used in the XML) (Table 2a)
Items in this column must conform to XML naming standards and be concatenateable.
13.2.6. Application Long Name (Table 2a)
This column reflects the actual use within EDI transaction, excluding segment stub
(segment stub is concatenateable based on context) and/or full descriptive name.
13.2.7. Definition of Data Element (Semantics / Description) (Table 2a)
This column includes information from the Implementation Guidelines for the specific
repository where applicable. This information could be linked to alternative standards
such as ISO 11179 for the central repository.
13.2.8. Repository Body (Table 2b)
This column indicates from which code and element dictionary we derived these
elements.
13.2.9. Valid Context or Pairing (Table 2b)
This column prevents indiscriminate use by noting combinations and structures where the
item is valid.
13.2.10. Purpose (Table 2b)
This column denotes whether the item is an element or some part of the markup of the
EDI transaction.
The purpose column allows us to build up XML tags based on the structure of
transaction. However, we need to ‘know’ that structure elsewhere then reference it here
to find out how to concatenate the right tag name or attributes for the DTD.
The purpose also defines when and how a particular item may be used.
Page 19
Preliminary Findings and Recommendations on XML-X12
13.3.
Version 1.0
Steps for Creating an X12/XML DTD from an XML DTD using Tables 2a
and 2b
Start from an XML formatted document, such as the following very simple one:
Document:
<Auto>
<Make>Aston Martin</Make>
<Model>DB6</Model>
<Year>87</Year>
Initial DTD:
<?xml version=“1.0”>
<!DOCTYPE Auto [
<!ELEMENT Auto (Make, Model, Year, Color, Price)>
]>
<Color>Dark Green</Color>
<Price>525000</Price>
</Auto>
The first tag is called <Auto>; this defines the actual document type. We search the X12
transaction and element archives and discover that this relates to X12 120 Vehicle
Shipping Order, and that the Unique ID for this is X12237 and that the Purpose from
Table 2 is “Transaction.”
Next we take item of <Make> and discover this corresponds to X12 element 93, ID2-05,
Manufacturer Name (see Appendix B) and that the Unique ID for that is X00345. From
Table 2 we know the Purpose is “Element,” and it is of Type “Character.”
Now we are ready to modify the DTD above to include this new information:
X12 DTD:
<?xml version=“1.0”>
<!DOCTYPE Auto [
<!ELEMENT Auto (Make, Model, Year, Color, Price)>
<!ATTLIST Auto
X12-number NUMBER #FIXED “X12237”
X12-purpose #FIXED “TRANSACTION”>
<!ATTLIST Make
X12-number NUMBER #FIXED “X00345”
X12-purpose #FIXED “ELEMENT”
X12-type #FIXED “CHARACTER”>
]>
This process is then continued for the remaining XML tag names within the DTD.
Page 20
Preliminary Findings and Recommendations on XML-X12
Version 1.0
14. XML Names Discussion
Each data item (segment, transaction set, loop and data element) in XML/EDI will have a
unique human-readable XML tag name derived from the X12 syntax and semantic X12
tables. Each XML tag name will be a concatenation of the words in the X12 name with
each word starting with a capital such as “TransactionSetHeader.” In addition, data
elements will receive a Unique ID, such as “X1258.”
Our next steps are:
1) define in much more detail the algorithms to generate these Unique IDs and the
names from the X12 tables
2) generate the purchase order, invoice, purchase order change notice, the advanced ship
notice, and the remittance advice as our first transaction sets
3) generate the DTDs for the initial transactions
The Unique ID will be used in the future to map between X12 and standards that use
topologies. The human-readable XML tag names will be what is used in the XML
document itself and will be defined in the DTDs. The human-readable XML tag names
are generated in a one-to-one manner from the X12 syntax, descriptions and semantic
meanings. They often use the X12 textual descriptions to create the names to make them
more human readable.
As mentioned previously, there will be two ways to describe a data element. The first is a
Unique ID, which is generated by a unique character sequence for each occurrence of
each data element within all transactions, segments and data element occurrences. The
Unique ID will be the means for mapping between all other standards. See Table 2b in
Section 13 above to see how this is done by equating the X12 Unique ID to its equivalent
identifier in the other repository (see column headed "Central Repository Cross Ref ID"
in Table 2b). The data element names only have meaning when the surrounding
XML/EDI transaction/segment/data-element are known. None of these data-element
names have complete semantic meeting without knowing the transaction and segment
and the placement in the segment. Each of these is important because a single data
element may have a different meaning depending on which transaction it is in, invoice or
advanced ship notice, which segment it is in and the placement in the segment. Some data
elements have a different meaning if they are the first occurrence in a segment than if
they are the second or third occurrence.
14.1.
Unique ID Generation
14.1.1. Unique IDs are not Data Element Numbers
Unique ID generation will require processing all the transaction tables in each subsequent
version of X12 to generate unique data element identifiers. We will start with one
transaction table and process them all in order generating names such as X23045. This
Unique ID will be the reference number much like the current data element name.
However, it is not a data element number because data element numbers do not show the
usage of the data element within each transaction, segment and occurrence in a segment.
The same data element repeating within a segment may have a different semantic
Page 21
Preliminary Findings and Recommendations on XML-X12
Version 1.0
meaning on each occurrence. Because of this, and the need to show each usage uniquely,
we will generate a Unique ID for each occurrence in a segment. If a data element is in a
repeating segment in a loop in exactly the same position — that is transaction, loop,
segment, and occurrence — it will have the same Unique ID. Otherwise, it will have a
different ID.
14.1.2. Algorithm for Generating Unique IDs
This algorithm assumes that a different NameSpace could be used for each release and
version of X12 for which the Unique ID is generated so that Unique IDs generated from
different versions will not conflict. However, it is not necessary to generate a unique ID
each version. It is only necessary to generate a unique ID for new data elements added for
that version. This will have to be discussed and documented in more detail in phase 2.
For each X12 release and version:
For each transaction set from lowest number to highest number:
For each segment in the transaction from lowest number to highest number:
Read the first element of the segment. Assign it the Unique ID X00001.
Read the next element of the segment. Assign it the next available Unique ID:
X00002, X00003 and so on, unless the element occurs in the same transaction set,
loop, segment and segment occurrence placement as a previous occurrence; then
assign it the previously defined Unique ID.
End Segment loop.
End Transaction table loop.
Note: The above may generate infrequently different Unique IDs for the same semantic
meaning of a data element, but will never generate the same ID for different data element
semantics. The latter is more important at this stage than the former.
This assumes that Unique IDs are within an XML NameSpace, a NameSpace specific to
each X12 version. The NameSpaces could have names such as X124010 or X123040.
14.2.
Human-readable XML Tag Generation
The Well-Formed PO in 14.3 with the expanded data element semantic names in
Appendix B is an example of how the XML tag names will be generated. We are
currently generating the remaining expanded data element names from the X12
semantics. Appendix B shows those that have been defined so far.
Page 22
Preliminary Findings and Recommendations on XML-X12
Version 1.0
14.2.1. Conventions
To keep the XML transaction as condensed as possible, we will abbreviate many of the
common nouns and adjectives that are used to make the names. The example below does
not currently show the abbreviation. The abbreviations will be built into the routines that
generate the names from the X12 syntax tables. The abbreviations could be items such as:

Information will be abbreviated as Info

Qualifier will be abbreviated as Qual

Code will be Code

Reference will be Ref

Identifier will be abbreviated as ID

All “date” datatypes would end in the word Date

All “ID” datatypes would end in the word “ID” or “Code”
Note that the portion of an XML PO below follows the X12 PO transaction table order
and structure for version 4010. The names are generated automatically from the Version
4010 Purchase Order transaction tables and shortened as appropriate to balance the need
for human readability with that of brevity.
Note that while not obvious in the below example, we could represent the
qualifier/value pairs so prevalent in the X12 data structures as one data element
such as:
<Price Qual = “USA”>xxxxx</Price>
where the Qual=“USA” is the value from the qualifier data element and xxxxx is
the value. Using this mechanism we do not need to show both elements, just the
value element qualified with the appropriate qualifier value.
In the below example, data element tags such as <PurposeTypeCode Code=“SU Status
Update”/> have the following meaning:

PurposeTypeCode is the data element name

Code = “SU Status Update” is read as the Code value is “SU,” and the meaning of the
code is “Status Update”
In the final implementation “SU Status Update” could occur in two ways: 1) as “SU
Status Update” or 2) just “SU” without the description. Both ways SHOULD be
supported.
We need to ensure that we always show from which version of the X12 the syntax and
semantics are derived. The below example shows what a human-readable XML/EDI
transaction would look like using the conventions above.
Page 23
Preliminary Findings and Recommendations on XML-X12
14.3.
Version 1.0
Well-formed Purchase Order Example
This is an example of an XML/EDI Purchase Order derived from X12 4010. The names
are derived programmatically from the X12 databases. For example, “Transaction Set
Header” is the descriptive name of the fourth element below. To create the
Segment_Name we have merely concatenated the descriptive name components into
“TransactionSetHeader.” The next section shows the DTD for this instance.
<?XML version=“1.0” encoding=“UTF-8”?>
<PurchaseOrder Version=”4010”>
<PurchaseOrderHeader>
<TransactionSetHeader X12.ID=“850”>
<TransactionSetIDCode code=”1234”/>
<TransactionSetNumber>000000001</TransactionSetNumber>
<ConventionRef>123456</ConventionRef>
</TransactionSetHeader>
<BeginningSegment>
<PurposeTypeCode Code=“SU Status Update”/>
<OrderTypeCode Code=“KN Purchase Order”/>
<ReleaseNumber>MTB 98765</ReleaseNumber>
<PurchaseOrderDate>19980401</PurchaseOrderDate>
<ContractNumber>151553</ContractNumber>
<AcknowledgmentTypeCode Code=“AK Acknowledge - No Detail or Change”/>
<InvoiceTypeCode Code=“IEL Invoice Electronically”/>
<ContractTypeCode Code=“CY Cost Plus Incentive Fee”/>
<PurchaseCategoryCode Code=“SS Student Services”/>
<SecurityLevelCode Code=“11 Competition Sensitive”/>
<TransactionTypeCode Code=“44 Interplant Shipment”/>
</BeginningSegment>
<Currency>
<EntityIdentifierCode Code=“17 Consultant’s Office”/>
<CurrencyCountryCode Code=“US”/>
<ExchangeRate>1234.00</ExchangeRate>
<EntityIdentifierCode Code=“02 Loan Broker”/>
<CurrencyCountryCode Code=“AU”/>
<CurrencyMarketCode Code=“ZUR Zurich (Switzerland) Exchange”/>
<CurrencyDateQual Qual=“915 Loan”>19980301</CurrencyDateQual>
<CurrencyTime>1250</CurrencyTime>
</Currency>
o
o
o
14.4.
DTD Name Definition Example for a Purchase Order
The following is the trunk-portion of a DTD for a purchase order. An instance of it is in
the preceding section. The purpose of this partial DTD is to show what the structure,
loops and names would look like as they are generated from the X12 syntax and semantic
databases. This example truncates many limbs of the tree and only shows those parts that
are relevant to the preceding instance in order to keep the example short as possible.
In the DTD below, the names are derived as follows from the X12 Transaction Set
Databases:

The XML/EDI Data_Element_Name is the X12 data element name from the
syntax tables or, when present, the expanded data element names (See
Appendix B) from the Data Element Semantic_Notes with all words capitalized
and concatenated. Example: <PurchaseOrderNumber>.
Page 24
Preliminary Findings and Recommendations on XML-X12
Version 1.0

The XML/EDI Segment_Name is the X12 segment name from the syntax tables
with all words concatenated and each starting with an uppercase letter. Example:
<PricingInformation>.

Loop_Name is composed of the XML/EDI Segment_Name of the first Segment
in the loop with the word “LOOP1” appended to the Segment_Name. If a loop
starting with the same Segment_Name occurs more than once in a transaction set
and is composed of different segments than the previous occurrence, then
“LOOPn” is appended to the name where “n” is the natural number 2 through x.
Example: <ServiceAllowanceChangeLOOP1>.
<?xml version=“1.0”>
<!DOCTYPE Purchase.Order […..
<!ELEMENT Purchase.Order (PurchaseOrderHeader, PurchaseOrderDetail,
PurchaseOrderTrailer)>
<!ELEMENT PurchaseOrderHeader (TransactionSetHeader, BeginningSegment, Currency?,
ReferenceID?, AdminCommunicationsContact?, TaxReference?,
FOBRelatedInstructions?, PricingInformation?, PeriodAmount?,
SalesRequirements?, Commodity?, ServiceAllowanceChangeLOOP1?, ……………………>
<!ELEMENT PurchaseOrderDetail (BaselineItemData, ItemID?, ServiceCharacteristicID?,
Currency……………>
<!ELEMENT PurchaseOrderTrailer (TransactionTotals?, MonetaryAmount?)?,
TransactionSetTrailer)>
<!-- ******* Loops ********-- >
<!ELEMENT ServiceAllowanceChangeLOOP1
(ServicePromotionAllowanceOrChangeInformation?,Currency?)>
<!--********Data Elements ***************-->
<!ELEMENT
BeginningSegment (TransactionSetPurposeCode, PurchaseOrderTypeCode,
PurchaseOrderNumber, ReleaseNumber, Date, ContractNumber?,
AcknowledgmentType?, InvoiceTypeCode? ContractTypeCode?, PurchaseCategory?,
SecurityLevelCode?, TransactionTypeCode? ) >
<!ELEMENT
Currency (EntityIDCode, CurrencyCode, ExchangeRate, EntityIDCode,
CurrencyCode, CurrencyMarketExchangeCode, DateTimeQualifier, Date, Time,
DateTimeQualifier, Date, Time, DateTimeQualifier, Date, Time,
DateTimeQualifier, Date, Time, DateTimeQualifier, Date, Time ) >
<!ELEMENT
TransactionSetHeader (TransactionSetIDCode, TransactionSetControlNumber
15. XML/EDI Semantics and the X12 868 Electronic Form Structure
Syntax definition is the purpose of the X12 868 message set. Syntax definition can be
used to describe Implementation Conventions (ICs) specific to an industry or to a trading
partner. Its structure could be useful to describe trading-partner specific implementation
issues that override the X12 standards and to allow automation of these ICs between
trading partners. This is an area that must be addressed in a later phase.
Page 25
Preliminary Findings and Recommendations on XML-X12
Version 1.0
16. Repositories and their Purpose
See the discussion document on repositories and XML/EDI at
http://www.xmledi.com/repository/xml-rep.htm. This includes links to EDIFACT
SIMAC discussions on the use of repositories as well.
17. XML and Object Technology
One related effort is the use of XML to facilitate OMG object exchanges. This effort is
covered in the XML and UREP (Universal Objects Repository) work (See
http://www.marketplace.unisys.com/products/urep/).
The effort of the ANSI ASC X12 Ad Hoc Task Group on XML/EDI is focused on
moving the existing X12 data structure into XML/EDI in a manner that retains semantic
and syntactical meaning between the X12 standards and the XML/EDI. What happens to
the XML/EDI results if the new OO-edi efforts become commercially available?
Because we will be generating the information from the existing X12 data, as that data is
translated and mapped to the new OO-edi products, the XML/EDI data should also be
easily mapped to the OO-edi products.
See the discussion document on UML, OO-edi, and XML/EDI at
http://www.xmledi.com/repository/uml-xml.htm.
Page 26
Preliminary Findings and Recommendations on XML-X12
Version 1.0
Appendix A — Full List of Requirements
Following is the entire list of items we voted on in the straw vote.
 We must be able to support names that are language specific, such as French or
Japanese, not just English.
 Each data element should have a non-English unique name such as X2857 and should
support various aliases.
 We must define the data element names in a manner that facilitates mapping between
X12 and other standards.
 We must name data elements in a manner that will reflect their relation to the X12
version.
 XML/EDI data element names should be based on 11179, and those efforts claiming
conformance should be evaluated and used if possible.
 We must be able to support X12 loops in XML.
 We must take advantage of nesting in XML to represent hierarchical data.
 XML files are very verbose compared to X12 files. We should endeavor to keep the
XML representation as short as possible to save space and bandwidth.
 We should endeavor to keep the XML representation as human readable as possible.
 The proposed XML/EDI architecture should accommodate business-system-tobusiness-system and human-to-human requirements.
 We must be able to differentiate data elements depending on which segment and
transaction they are used.
 We should strive to conform to the intent of ISO/IEC 11179-5.
 We should identify suitable registration authority candidate(s) to satisfy the intent of
ISO/IEC 11179-6.
 It is more important that we really use the XML/EDI capabilities than it is to make it
completely backward compatible to X12.
 XML should be backward compatible to X12, if at all possible.
 Rather than providing exact equivalent XML for all X12 transaction sets, examples
and a “cookbook” will be provided to ensure people can derive their own compliant
implementation conventions using XML.
 It is important that we retain as much information as possible about data elements, by
naming them clearly from the X12 data element names, so that content experts can
use existing expertise in mapping data elements between applications, EDI and
XML/EDI.
 We should solve the needs of the SME by modeling standard business processes that
can be expressed and documented in a UML (Universal Modeling Language) model.
Page 27
Preliminary Findings and Recommendations on XML-X12
Version 1.0
This leads to low-cost software that can be implemented in what method or language
the developer pleases, but can pass data (including XML) to populate business objects
utilized within these applications.
 We should provide the SME wizard-based mapping tools that dynamically match
fields from one application to another application, only prompting the administrator
when an exception occurs.
 The SME does not care what format the data is represented in as long as it is
distinguishable, parsable and mappable. XML/EDI should not require the SME to
look at the data stream.
Page 28
Preliminary Findings and Recommendations on XML-X12
Version 1.0
Appendix B — Partial List of Data Element Name Extensions
The following Data Element names were developed to clarify the semantic meaning of a
Data_Element. The names are derived from the data element semantic notes. The same
data element, for example, 610, may have multiple semantic meanings depending on
where it is used. Data element 610 below has different meanings depending on where it
occurs in a segment, although they are all related to price. As we generate
Data_Element_Names, we will use more semantically correct meanings to produce the
data element names. For example, the Data_Element_Name for the first “610” will be
PriceChangeAmount and for the second OldPrice.
DE Number
PSDE
DESCRIPTION / NEW XML TAG NAME
-------------373
782
782
373
373
1470
610
610
610
380
380
380
782
954
782
1470
380
373
380
380
373
373
373
373
373
373
373
127
127
373
127
127
373
373
337
373
127
373
373
337
127
127
373
127
373
373
373
373
127
373
----------A4-07
ADJ-02
ADJ-03
ADJ-04
ADJ-05
ADJ-06
ADJ-10
ADJ-11
ADJ-12
ADJ-13
ADJ-14
ADJ-15
AIN-03
AP1-04
AP1-05
AP1-09
AP1-10
ATH-02
ATH-03
ATH-04
ATH-05
B1-03
B3-06
B4-04
B11-03
B3B-03
B3B-05
BA2-04
BA2-05
BA2-10
BA3-04
BA3-05
BA3-11
BAA-03
BAA-06
BAK-04
BAK-08
BAK-09
BC-02
BC-03
BC-04
BC-05
BCA-06
BCA-09
BCA-10
BCA-11
BCA-12
BCH-06
BCH-09
BCH-10
---------------------------------------------------------Waybill Date
Adjustment Amount
Adjustment to Average Collected Balance
Original Financial Transaction Date
Adjustment Processed Date
Number of Days
Price Change Amount
Old Price
New Price
Volume Change Quantity
Old Volume
New Volume
Income Amount
Minimum Savings Percent
Minimum Savings Dollars
Max Number of Suppliers Allowed
Vehicle Age Delimiter (Qty)
Resource Authorization Thru Date
Current Cumulative Requirements Qty
Maximum Cumulative Requirements Qty
Cumulative Start Date
Booking Date
Billing Date
Status Date
Pick-up Date
Billing Date
Payment Due Date
Terminal Operator Reference Number
Broker Number
Arrival Date
Terminal Operator Reference Number
Broker Number
Arrival Date
Account Adjustment Date
Account Adjustment Time
Purchase Order Date
Seller’s Order Number
Acknowledgement Date
Preparation Date
Preparation Time
Transaction Reference Number
Previous Transaction Reference No.
Purchase Order Date
Seller’s Order Number
Acknowledgment Date
Purchase Order Request Change Date
P.O. Change Acknowledgment Date
Purchase Order Date
Seller’s Order Number
Acknowledgment Date
Page 29
Preliminary Findings and Recommendations on XML-X12
373
127
373
373
373
373
373
373
373
373
127
127
373
337
373
373
127
954
954
373
373
373
373
373
782
782
373
782
373
782
127
373
337
127
373
337
373
373
373
610
373
127
373
373
782
127
373
127
127
373
337
373
782
782
380
380
380
380
782
212
782
127
127
373
127
373
127
373
127
782
BCH-11
BCI-03
BCM-02
BCM-03
BCO-03
BCO-06
BCO-07
BCP-04
BCP-07
BCP-08
BCP-10
BCP-11
BCQ-02
BCQ-03
BCS-02
BCS-04
BCS-07
BCS-10
BCS-11
BEG-05
BFR-06
BRF-07
BFR-08
BFR-09
BFS-02
BFS-04
BFS-05
BFS-06
BFS-07
BFS-08
BGN-02
BGN-03
BGN-04
BHT-02
BHT-03
BHT-04
BIG-01
BIG-03
BM-02
BM-03
BM-05
BMA-02
BMA-04
BMA-05
BMA-07
BMP-02
BMS-02
BMS-04
BNR-02
BNR-03
BNR-04
BOS-02
BOX-04
BOX-06
BOX-07
BOX-08
BOX-09
BOX-10
BOX-11
BOX-12
BOX-13
BPX-14
BPX-15
BPP-02
BPP-06
BPP-07
BPP-09
BPP-11
BPP-12
BPR-02
Purchase Order Request Change Date
Policy Number
Transaction Set Effective Date
Report Effective Date
Request for Quote Control Date
Contract Beginning Date
Contract Expiration Date
Proposer’s Fiscal Year Start
Transaction Creation Date
Transaction Creation Time
Proposal Revision Number
Proposal Option Number
Transaction Date
Transaction Time
Transaction Date
Report Effective Date
Program Number ID
Customer Share Ratio Number
Contractor Share Ratio Number
Purchase Order Date
Forecast Horizon Start Date
Forecast Horizon End Date
Forecast Generation Date
Date Forecast Updated
Borrower Income Amount
Borrower Expense Amount
Asset Total Effective Date
Borrower Asset Total
Borrower Liability Effective Date
Borrower Liability Total
Transaction Set Reference Number
Transaction Set Date
Transaction Set Time
Transaction Set Number
Transaction Set Creation Date
Transaction Set Creation Time
Invoice Date
Purchase Order Date
Billing Date
Net Amount Due
Bill Due Date
Fund ID Number
Beginning Fund Date
Ending Fund Date
Development Fund Monetary Amount
Fund Event ID Number
Report Effective Date
Report Identifier
Nonconformance Report ID Number
Report Creation Date
Report Creation Time
Period Ending Date
Gross Box Office Receipts
Total Tax Amount
Total Number of Tickets Sold
Total Tickets Refunded and Voided
Total Tickets Refunded
Total Tickets Voided
Amount of Other Deductions
Individual Ticket Price
Tax Per Ticket
Opening Ticket Number
Closing Ticket Number
Transaction Set Date
Program ID Number
Report Effective Date
Schedule ID Number
Schedule Date
Priority Rating Reference Number
Payment Amount
Page 30
Version 1.0
Preliminary Findings and Recommendations on XML-X12
373
782
373
373
127
373
337
127
373
373
373
337
373
373
373
127
373
337
373
337
127
373
337
127
373
337
127
373
373
373
127
373
127
373
373
337
373
337
127
782
954
954
380
373
100
100
127
1251
1251
1251
373
373
58
58
782
782
782
782
380
380
1251
1251
1251
1251
1251
58
782
782
782
127
BPR-16
BPS-02
BPS-12
BPS-13
BPT-02
BPT-03
BPT-08
BPT-09
BQR-03
BQT-03
BRA-02
BRA-05
BSC-02
BSC-03
BSC-04
BSI-01
BSI-02
BSI-06
BSN-03
BSN-04
BSR-03
BSR-04
BSR-07
BSR-08
BSR-09
BSR-10
BSS-02
BSS-03
BSS-05
BSS-06
BSS-08
BTA-02
BTC-05
BTI-05
BTP-03
BTP-04
BTR-03
BTR-04
BTR-05
BUY-03
BUY-04
BUY-05
BVB-06
C2-07
C3-01
C3-03
CCI-02
CCI-06
CCI-07
CCI-08
CD1-08
CD1-25
CD3-08
CD3-10
CDA-02
CDA-03
CDA-04
CDA-05
CDA-08
CDA-09
CDA-11
CDA-12
CDA-13
CDA-14
CDA-15
CGS-01
CLP-02
CLP-03
CLP-04
CLP-07
Effective Entry Date
Payment Amount
Effective Entry Date
Settlement Date
Transfer/Resale Number
Transfer/Resale Date
Transfer/Resale Time
Previous Report Number
Request Quotation Control Date
Request Quotation Control Date
Transaction Creation Date
Transaction Creation Time
Transaction Creation Date
Reporting Period Start Date
Reporting Period End Date
Inquiry Reference Number
Inquiry Reference Date
Inquiry Reference Time
Transaction Creation Date
Transaction Creation Time
Report Number Assigned by Sender
Report Date from Sender
Report Time from Sender
Report Number Assigned by Inquirer
Date Requested from Inquirer
Time Requested from Inquirer
Document Number
Document Date
Schedule Horizon Start Date
Schedule Horizon End Date
Forecast ID No Assigned by Purchaser
Effective Date
Trace ID Number
Transaction Creation Date
Transaction Set Date
Transaction Set Time
Transaction Creation Date
Transaction Creation Time
Test Results Report Reference Number
Total Buydown Amount
Percent of Permanent Payment Decrease
Percent of Permanent Rate Decrease
Yard Storage Capacity
Effective Payment Date
Billing Currency Code
Payment Currency Code
Credit File ID or Hit Level
Date Counseling Reported
Date Counseling Checked
Date Counseling Settled
Deliver Not Before Date
Delivery Date
Charge for Single Package
Total Charge for All Packages
Credit Account Balance
Credit Account Original Balance
Credit Account Past Due Amount
Credit Account Minimum Payment Amount
No of Months Credit Account Reviewed
No of Months Credit Account Remaining
Date Credit Account Opened
Date Last Credit Account Activity
Date Credit Account Closed
Date Credit Account High Delinquent
Date Credit Account Payoff Due
Freight Charge
Amount Submitted Charges This Claim
Amount Paid This Claim
Patient Responsibility Amount
Payers Internal Control Number
Page 31
Version 1.0
Preliminary Findings and Recommendations on XML-X12
373
373
642
782
332
373
380
609
380
380
380
380
380
380
380
373
954
954
373
373
610
373
954
1251
1251
782
380
380
380
782
782
782
782
782
373
373
1251
782
782
782
373
610
1251
1251
337
337
373
373
542
542
610
1470
1470
127
1251
380
380
782
954
782
954
610
610
380
954
380
782
1251
93
380
CM-08
CMA-04
CMA-05
CN1-02
CN1-03
CPR-02
CR1-06
CR2-01
CR2-02
CR2-06
CR2-07
CRS-03
CRS-04
CRS-17
CRS-18
CRS-19
CS-09
CS-10
CSD-05
CSD-06
CSH-03
CSH-05
CSH-09
CSU-04
CSU-06
CTP-08
CV-05
CV-07
CV-08
CV-09
CV-10
CV-11
CV-12
CV-13
DAD-03
DAD-04
DB-02
DB-03
DB-04
DB-05
DED-03
DED-04
DEF-03
DEG-03
DH-02
DH-03
DK-07
DK-08
DL-02
DL-03
DL-05
DL-06
DL-07
DMA-03
DMG-02
DN1-01
DN1-02
DOS-02
DOS-03
DOS-04
DOS-05
DP-03
DP-04
DP-11
DP-14
DSB-02
DSB-06
DVI-05
DVI-06
DVI-07
Manifest Date
Campaign Start Date
Campaign Week Number
Contract Amount
Allowance/Charge Percent
Commodity Market Price Date
Distance Traveled During Transport
Number This Treatment in Series
Total Number of Treatments in Series
Time Period in Treatment Series
No. of Treatments Rendered in Month
Course Credit Value
Course Credit Earned
Student’s Days Attended
Student’s Days Absent
Date Student Dropped Course
Permissible Overage Percent
Permissible Shortage Percent
Pick-up Date
Delivery Date
Do-Not-Exceed Amount
Required Invoice Date
Set-Aside Percent
Course Beginning Date
Course Ending Date
Rebate Amount
Time Units
Loaded Mile Units
Empty Mile Units
Total Value
Time Value
Mile Value
Appurtenance Value
Penalty Value
Earliest Date Debit Can Be Applied
Last Date Debit Can Be Applied
Disbursement Date
Net Disbursement Amount
Lender Origination Fee
Guarantor Insurance Premium
Payment Date
Payment Amount
Deferment Period Date Range
Date Degree Awarded
Start Time Dealer’s Hours
End Time Dealer’s Hours
Docket Effective Date
Docket Expiration Date
Actual Labor Hours
Estimated Labor Hours
Labor Amount
Number of Paint Stages
Number of Paint Tones
Driver’s License Number
Date of Birth
Number of Treatment Months
No. of Treatment Months Remaining
Max Dollar Amount of Campaign Share
Max Percentage of Campaign Share
Min Dollar Amount of Campaign Share
Min Percentage of Campaign Share
Actual Part Price
Estimated Part Price
Part Quantity Used
Adjustment/Betterment Percent
Scheduled Work Days Before Disability
Max Amount of Disability Coverage
Purchase Date
Place of Purchase
Current Mileage
Page 32
Version 1.0
Preliminary Findings and Recommendations on XML-X12
127
1251
373
337
954
81
183
373
1251
373
380
337
380
373
127
610
373
610
542
542
610
610
373
127
127
373
127
127
127
127
373
373
543
543
373
610
373
373
373
373
782
782
380
954
782
1470
782
782
373
782
782
782
782
373
337
373
373
373
373
380
1470
782
782
380
1470
1470
610
782
373
337
DVI-08
DVI-11
E7-05
E7-06
EC-04
EM-02
EM-04
EM-07
ENR-04
ER-10
ES-05
ESI-04
ESI-05
F01-01
F01-02
F01-03
F02-01
F07-05
F07-11
F07-12
F09-04
F09-05
F10-01
F10-02
F10-03
F11-01
F11-02
F11-03
F12-01
F12-02
F12-03
F12-05
F12-06
F12-07
F13-02
F13-03
F13-05
F6X-07
F6X-08
FAA-03
FAA-04
FAA-06
FAA-08
FC-02
FC-03
FC-04
FCL-04
FIR-03
FIR-04
FIS-02
FIS-03
FIS-04
G3-05
G4-04
G4-05
G5-04
G01-01
G01-03
G06-02
G13-02
G13-04
G13-05
G17-14
G29-02
G30-02
G32-01
G33-01
G35-03
G36-03
G37-02
Vehicle License Plate Number
License Plate Year
Estimated Interchange Date
Estimated Interchange Time
Percent of Ownership
Maximum Load Weight
Maximum Load Volume
Last Inspection Date
Anticipated Completion Date
Train Origination Date
Time to Repair Equipment
Start Time of Day of Injury
Number of Hours Worked Last Day
Claim Date
Claim Number
Claim Amount
Actual Ship Date
Amount Claimed Per Unit
Associated Labor Hours
Non-associated Labor Hours
Amount Claimed Per Unit
Amount Claimed for a Line Item
Claim Date
Claimant Claim Number
Carrier Claim Number
Claim Date
Claimant Claim Number
Carrier Claim Number
Dealers Repair Order Number
Dealers Document Number
Repair Order Date
Debit/Credit Memo Date
Body Repair Rate
Chassis Repair Rate
Check Date
Check Amount
Redemption Date
Factory Shipment Date
Dealer Delivery Date
Date Account Opened
Current Balance Amount
Average Balance Amount
Number of Time Periods
Percent Salary Contribution
Amount of Contribution
Number of Yearly Payments
Authorized Bid Amount
Transaction Amount
Posted Date
Credit Amount
Debit Amount
Interest Amount
Amount on Which Compensation Based
Event Date
Event Time
Waybill Date
Invoice Date
Purchase Order Date
Delivery Date
Size of Store
Number of Check-out Lanes
Weekly Dollar Sales Amount
Cum Amount on Unsalable Merchandise
Number of Displays/Qty of Product
Number of Electronic Displays
Ad Hoc Survey Question Number
Total Invoice Amount
Coupon Value Amount
Price List Issue Date
Activity Start Time
Page 33
Version 1.0
Preliminary Findings and Recommendations on XML-X12
337
610
332
373
373
610
610
610
373
332
610
373
1470
373
373
1251
1251
1251
782
953
953
127
1251
380
1251
782
782
127
118
782
380
609
609
1251
609
1251
127
127
782
380
93
93
782
1251
954
380
380
782
1251
1251
380
954
782
380
782
1251
373
337
373
373
337
373
337
1251
337
337
610
373
332
380
G37-03
G46-05
G46-07
G48-02
G48-04
G49-01
G49-02
G49-03
G50-02
G72-09
G76-08
G92-02
G95-07
GA-08
GH-02
GR-04
GR-06
GR-08
GR-09
GR-10
GR-12
GR-14
GR-16
GR-20
HC-04
HCP-02
HCP-03
HCP-04
HCP-05
HCP-07
HCP-12
HD-06
HD-07
HS-03
ICH-01
ICH-03
ICH-05
ICH-06
ICM-02
ICM-03
ID2-05
ID2-06
IDB-03
IMM-03
IMP-02
INC-03
INC-04
INC-05
INS-12
INT-04
INT-05
INV-02
INV-03
INV-04
INV-07
IRA-03
IS2-05
IS2-06
IS2-10
IS2-12
IS2-13
IS2-14
IS2-15
ISC-05
ISC-06
ISD-04
IT8-03
IT8-05
ITA-09
ITA-10
Activity End Time
Allowance/Charge Total Amount
Allowance/Charge Percent
Invoice Date
Purchase Order Date
Total Statement Amount
Prior Balance
Current Balance
Purchase Order Date
Allowance/Charge Percent
Total Purchase Order Amount
Purchase Order Date
Number of Days in Promotion Period
Unload Date
Effective Date
Loan Period
Result Date
Loan Status Date
Guaranteed Loan Amount
Current Interest Rate
New Interest Rate
Guarantor Loan ID
Guarantee Expiration Date
Number of Grace Months
Date Condition First Encountered
Allowed Amount
Savings Amount
Repricing Organization ID Number
Pricing Rate
Approved DRG Amount
Approved Service Units/Days
Number of Collateral Dependents
Number of Sponsored Dependents
Health Screening Date
Chronological Age
Date of Birth
Social Security Number
Driver’s License Number
Yearly Wages Amount
Weekly Hours
Manufacturer Name
Brand Name
Outstanding Balance
Immunization Date
Percent Impairment
Total Number of Installments
Number of Current Installments
Installment Balance
Date of Death
Interest Date Range
Number of Days in Range
Contribution Percent
Deposit Amount
Number of Units/Shares
Current Investment Fund Balance
Effective Date
Scheduled Event Date
Scheduled Event Time
Train Origination Date
Earliest Cutoff Date
Earliest Cutoff Time
Latest Cutoff Date
Latest Cutoff Time
Service Commitment Date
Cutoff Time
Cutoff Time
Do-Not-Exceed Amount
Required Invoice Date
Allowance/Charge Percent
Allowance/Charge Quantity
Page 34
Version 1.0
Preliminary Findings and Recommendations on XML-X12
380
373
58
373
373
373
380
373
127
782
1251
127
782
1251
782
954
782
782
954
954
782
508
954
954
1251
1251
1251
1251
1251
782
782
782
954
782
782
782
1470
234
234
234
234
373
373
373
373
380
127
225
225
782
373
782
118
610
610
610
380
380
380
127
954
610
380
954
954
373
954
782
782
782
ITA-12
JIL-06
L3-05
L7-10
L7A-07
L7A-08
LC-05
LDT-04
LEQ-07
LEQ-08
LID-02
LN-01
LN-02
LN-04
LN-06
LN-07
LN1-01
LN1-04
LN1-05
LN1-06
LN1-08
LN1-13
LN1-14
LN1-15
LN1-17
LN1-18
LN1-19
LN1-20
LN1-21
LN1-22
LN1-23
LRQ-01
LRQ-02
LRQ-04
LRQ-11
LRQ-12
LRQ-19
LS1-04
LS1-05
LS1-06
LS1-07
M0-02
M0-03
M0-04
M14-05
M14-09
M14-10
M7A-01
M7A-02
MCD-01
MCD-02
MCD-03
MCT-06
MI-02
MI-03
MI-04
MIA-01
MIA-02
MIA-03
MIR-04
MIR-05
MIR-06
MIR-08
MIR-09
MIR-10
MIR-12
MOA-01
MOA-02
MOA-08
MOA-09
Free Goods Quantity
Transaction Date
Total Charges
Effective Date
Effective Date
Expiration Date
Salary Multiplier
Effective Date
Lessor Number
Total Mileage Detail Earnings Amount
Date and Time Loss Occurred
Loan Number
Account Balance
Date of Loan
Payment Amount
Loan Interest Rate
Unpaid Load Principal Balance
Original Principal Balance
Current Loan Note Rate
Loan to Value Ratio
Current Principal & Interest Payment
Lender’s Account Number
Original Payment Rate
Qualifying Loan Rate
Loan Note Date
First Installment Due Date
Last Paid Installment Date
Date Loan Interest Paid to
Next Payment Installment Due Date
Amount of Other Financing
Current Balance of Negative Amortztn
Principal Amount Requested
Requested Interest Rate Percent
Initial Principal & Interest Payment
Total Amount of Existing Liens
Total Debt Amount Paid by Proceeds
Number Months of Mortgage Term
Manufacturer’s Part Number
Manufacturer
Type
Model
Issue Date
Expiration Date
On Board Vessel Date
Release Issue Date
Quantity Released or Requested
IRS ID Number of Carrier
Original Seal Number
Replacement Seal Number
Property Sales Price Amount
Loan Settlement Date
Purchase Deposit Amount
Transportation Charge
Budgeted Amount
Amount to Be Shared
Actual Cost
Covered Days
Lifetime Service Days
Lifetime Psychiatric Days
Certificate of Insurance Number
Initial Term Premium Percentage
Initial Term Premium Amount
Term of Mortgage Insurance
Mortgage Insurance Amount Percent
Loan to Value Ratio
Coverage Expiration Date
Reimbursement Rate
HCPCS Payable Amount
ESRD Payment Amount
Amount Billed But Not Payable
Page 35
Version 1.0
Preliminary Findings and Recommendations on XML-X12
65
373
373
373
127
93
1251
1251
380
373
610
610
782
782
782
1251
782
954
782
954
782
380
380
954
954
782
380
954
782
954
782
127
380
380
1251
1251
782
373
782
954
127
1470
782
373
373
127
93
1251
373
337
373
782
1251
782
380
1251
1470
1470
1470
1470
1470
1470
373
373
782
373
373
127
127
953
N5-06
N8-02
N8-07
N8A-03
N8A-04
OP-03
OPX-02
OPX-04
P4-03
PAI-01
PAI-04
PAI-05
PAS-03
PAS-04
PAS-05
PAT-06
PAY-02
PAY-03
PAY-04
PAY-05
PAY-06
PAY-08
PAY-10
PAY-11
PAY-12
PAY-13
PAY-15
PAY-16
PAY-17
PAY-19
PAY-20
PBI-01
PBI-05
PBI-07
PCL-04
PCL-06
PCS-05
PD-02
PEN-02
PEN-04
PEN-06
PEN-07
PEX-03
PI-12
PI-13
PIN-03
PIN-04
PIN-06
PLA-03
PLA-04
PLB-02
PLI-02
PLI-06
PLI-07
PLI-08
PPD-03
PPD-08
PPD-09
PPD-10
PPD-11
PPD-12
PPD-13
PPL-02
PPL-03
PPY-02
PR2-01
PR2-02
PR2-07
PR2-09
PRC-04
Height in Inches
Waybill Date
Waybill Date
Waybill Date
Revenue Reference Waybill ID Number
Program Name
Placement Date
Last Participation Date
Number of Bills of Lading
Advertisement Date
Budget Amount
Actual Cost
Estimate of Property Value
Estimated Cost Property Improvements
Estimated Value after Improvements
Date of Death
Current Payment Amount
Payment Adjustment Cap Percent
Payment Adjustment Cap Amount
Payment Adjustment Life Cap Percent
Payment Adjustment Life Amount
Number of Periods
Number of Periods
Initial Payment Rate Percent
Optional Payment Cap Percent
Optional Payment Cap Amount
Number of Scheduled Payment Changes
Scheduled Payment Change Percent
Scheduled Payment Change Amount
Negative Amortization Cap Percent
Negative Amortization Cap Amount
Error ID Number
Copy of Bad Data Element
Data Element New Content
Attendance Date Range
Year Degree Awarded
Claim Amount Paid
Start Date
Transaction Total Amount
Contribution Percent of Salary
Loan Identification Number
Number of Load Repayments
Expense Amount
Effective Date
Expiration Date
Policy Number
Insurance Company Name
Date Loss Occurred
Effective Date
Effective Time
Last Day of Providers Fiscal Year
Previous Loan Amount
Previous Loan Period Date Range
Previous Loan Amount Owed
Loan Term in Months
Payment Period Start Date
Number Times Payments 30 Days Late
Number Times Payments 60 Days Late
Number Times Payments 90 Days Late
Number Times Payments 120 Days Late
Number Times Payments 150 Days Late
Number Times Payments 180+ Days Late
Start Date
End Date
Personal Property Value
Beginning Date
Ending Date
Rate Type Request Number
Group Definition Request Number
Index Value
Page 36
Version 1.0
Preliminary Findings and Recommendations on XML-X12
953
953
380
954
380
380
380
782
373
93
373
488
127
782
373
373
373
373
373
373
373
337
373
373
373
373
954
954
954
380
380
954
954
954
380
373
380
1470
127
127
782
782
782
782
782
782
782
782
782
1470
1470
127
127
373
373
373
373
373
332
118
380
380
373
373
234
1470
380
380
1251
782
PRC-05
PRC-06
PRD-02
PRD-05
PRD-06
PRD-07
PRD-10
PRD-11
PRF-04
PRJ-01
PRJ-04
PRO-03
PS1-01
PS1-02
PSC-10
PSC-11
Q2-03
Q2-04
Q2-05
Q3-01
Q5-02
Q5-03
R2-10
R3-07
RA-09
RA-10
RAT-04
RAT-05
RAT-06
RAT-08
RAT-10
RAT-12
RAT-13
RAT-14
REA-02
REA-03
REC-05
REL-02
RES-04
RES-05
RMR-04
RMR-05
RMR-06
RMT-03
RMT-04
RMT-05
RMT-06
RMT-07
RMT-08
RTE-04
RTE-05
RU1-02
RU1-04
RU1-05
RU1-08
RU2-03
RU3-01
SA-01
SAC-07
SAC-08
SAC-10
SAC-11
SAL-06
SAL-07
SCM-01
SCM-02
SCO-01
SCT-02
SCT-05
SER-03
New Pass Through Rate
New Note Rate
Initial Term in Months
Initial Interest Accrual Rate
Amortization Term in Months
Maximum Load Term in Months
No. of Months until Balloon Paymt
Amount of Balloon Payment
Purchase Order Date
Housing Project Name
Approval Date
Percent Fuel Remaining
Provider ID
Cost of Service
Thru Date
Beginning Date
Required Pier Date
Vessel Departure Date
Shipment Unload Date
Estimated Arrival Date
Status Date
Status Time
Billing Date
Billing Date
Effective Date
Expiration Date
Adjustment Margin Percent
Initial Index Percent
Periodic Interest Rate Cap Percent
No of Periods for Periodic Rate Cap
No of Periods Between Rate Changes
Interest Rate Life Cap Percent
Interest Rate Life Floor Percent
Rounding Percent
Number of Living Units
Date Property Was Acquired
Number of Living Units
Birth Order (Ordinal Number)
Calendar Number ID
Shift Number ID
Amount Paid
Total Invoice or Credit-Debit Amt.
Amount of Discount Taken
Amount Paid
Total Invoice or Credit-Debit Amt.
Amount Subject to Terms Discount
Discounted Amount Due
Amount of Discount Taken
Other Amount Deducted or Added
No. of Days in Analysis Month
No. of Days in Analysis Year
Social Security Number
Employee’s ID Number
Date Employee Last Worked
Claim Begin Date
Effective Date
Claim Begin Date
Activity Date
Allowance or Charge Percent
Allowance or Charge Rate
Allowance or Charge Quantity
Allowance or Charge Quantity
Reporting Period Start Date
Reporting Period End Date
Credit Score Model
Credit Score Number
Quantity Ordered
Number of Credit Hours
Date of School Term
Collected Balance Required
Page 37
Version 1.0
Preliminary Findings and Recommendations on XML-X12
782
373
373
373
373
782
782
1251
1251
1251
782
380
380
380
373
1251
1470
373
954
380
609
609
609
337
337
380
373
373
373
373
373
373
373
373
610
1251
1251
373
782
782
373
373
380
380
380
380
1251
380
380
782
782
782
782
782
782
782
782
380
782
782
234
380
380
373
380
954
373
337
782
782
SER-04
SHP-04
SHP-06
SID-04
SL1-05
SLI-02
SLI-03
SLI-07
SLI-11
SLI-13
SLI-14
SLI-15
SLI-16
SLI-17
SMA-06
SOI-03
SOI-04
SOM-06
SP-05
SPO-04
SPS-01
SPS-02
SPS-03
SR-03
SR-04
SR-07
SR-08
SR-09
SS-01
SS-05
SS-06
SS-08
SSE-01
SSE-02
SSS-06
SST-03
SST-06
STC-02
STC-04
STC-05
STC-06
STC-08
SUM-04
SUM-05
SUM-06
SUM-12
SUM-14
SUM-04
SUM-04
SV1-02
SV1-08
SV2-03
SV2-07
SV3-02
SV5-04
SV5-05
SV6-04
SV6-06
SVC-02
SVC-03
SVC-04
SVC-05
SVC-07
T1-03
TBA-02
TBA-03
TCD-02
TCD-03
TCD-12
TCD-13
Service Charge
Cumulative Quantity Start Date
Cumulative Quantity End Date
Deregulation Date
Effective Date
Requested Load Amount
Total Load Amount Approved
Loan Period Date Range
Repayment Begin Date
First Payment Date
First Payment Amount
Number of Monthly Payments
Number of Grace Months
Number of Capitalization Months
Begin Date Info Effective
Date of the Income
Number of Months of the Income
Bankruptcy Filing Date
Percent Time Mainstreamed
Total Purchase Order Quantity
Population Size
Sample Size
Subgroup Size
Promotion Start Time
Promotion End time
Number of Scheduled Commercial Spots
Promotion Start Date
Promotion End Date
Effective Date
Independence Trigger Date
Effective Date for RCCR Increases
Effective Date for Selective Increases
Entry Date
Exit Date
Allowance or Charge Total Amount
High School Graduation Date
Date Student Eligible to Return
Effective Date of Status Info
Amount of Original Submitted Charges
Amount Paid
Date Paid
Check Issue Date
Credits for Computation
Credits Attempted
Credits Earned
Number in Class
Date of Class Ranking
Number of Days Attended
Number of Days Absent
Submitted Charge Amount
Lab Charges
Submitted Charge Amount
Non-covered Charge Amount
Submitted Charge Amount
Rental Price
Purchase Price
Submitted Charge
Number of Anesthesia Minutes
Submitted Service Charge
Paid Amount
NUBCR Code
Paid Units of Service
Submitted Units of Service
Shipment Waybill Date
Number of Periods
Temporary Buydown Percent
Date of Call
Connect Time of Call
Undiscounted Amount
Net Amount after Discount
Page 38
Version 1.0
Preliminary Findings and Recommendations on XML-X12
782
782
610
610
610
610
373
380
380
373
782
127
127
373
1251
782
1251
782
1470
373
380
380
782
782
782
782
782
782
380
782
782
380
380
380
380
380
782
380
782
782
782
127
373
380
782
782
782
782
782
782
782
782
782
782
782
782
782
782
782
782
782
782
380
782
1251
782
380
380
373
782
TCD-14
TCD-15
TDS-01
TDS-02
TDS-03
TDS-04
TFS-07
THE-04
THE-05
TI-05
TIA-07
TID-07
TID-08
TIS-02
TLN-13
TLN-14
TLN-17
TLN-18
TLN-21
TMD-07
TRF-03
TRF-05
TS2-01
TS2-02
TS2-03
TS2-04
TS2-05
TS2-06
TS2-07
TS2-08
TS2-09
TS2-10
TS2-11
TS2-12
TS2-13
TS2-14
TS2-15
TS2-16
TS2-17
TS2-18
TS2-19
TS3-01
TS3-03
TS3-04
TS3-05
TS3-06
TS3-07
TS3-08
TS3-09
TS3-10
TS3-11
TS3-12
TS3-13
TS3-14
TS3-15
TS3-16
TS3-17
TS3-18
TS3-19
TS3-20
TS3-21
TS3-22
TS3-23
TS3-24
TST-04
TSU-03
TSU-04
TSU-05
TSU-06
TXI-02
Undiscounted Amount
Net Amount after Discount
Total Invoice Amount
Amount Subject of Terms Discount
Discounted Amount Due
Terms Discount Amount
Tax Period End Date
Number of Screens Being Reported
Number of Pictures Being Reported
Railroad Waybill Date
Flat Fee Tax Rate
Calendar Number ID
Shift Number ID
Date Required
Last Known Past-due Date
Last Known Past-due Amount
Date of Highest Delinquency
Highest Delinquency Amount
Number Months in Term of Tradeline
Test Method Date
Equivalent Units per Standard Unit
Standard Unit
Diagnosis Related Group Amount
Federal Specific Amount
Hospital Specific Amount
Disproportionate Share Amount
Capital Amount
Indirect Medical Education Amount
Number of Outlier Days
Day Outlier Amount
Cost Outlier Amount
DRG Average Length of Stay
Number of Discharges
Number of Cost Report Days
Number of Covered Days
Number of Non-covered Days
MSP Passthrough Amount
Average DRG Weight
PPS Federal Specific Portion Amount
PPS Hospital Specific Portion Amount
PPS Disproportionate Share Amount
Provider Number
Last Day of Provider Fiscal Year
Number of Claims
Reported Charges
Covered Charges
Non-covered Charges
Denied Charges
Provider Payment
Amount of Interest Paid
Contractual Adjustment
Gramm_Rudman Reduction
Medicare Secondary Payer Amount
Blood Deductible Amount
Summary of Non-lab Charges
Coinsurance Amount
HCPCS Reported Charges
HCPCS Payable Amount
Deductible Amount
Professional Component Amount
MSP Patient Liability Met Amount
Patient Reimbursement Amount
PIP Number of Claims
PIP Adjustment Amount
Date Test Administered
Summary Transaction Amount
Summary Number of Transactions
Detailed Number of Transactions
Date Processed
Tax Amount
Page 39
Version 1.0
Preliminary Findings and Recommendations on XML-X12
954
380
118
954
380
380
610
127
81
81
81
81
81
93
82
373
373
397
397
782
751
751
751
1251
380
373
373
373
408
408
408
408
31
31
373
408
610
337
337
373
373
373
373
373
380
610
373
373
373
373
373
373
373
373
373
TXI-02
UR-02
USD-03
USD-04
USD-06
USD-07
USD-09
V2-02
V2-03
V2-05
V2-07
V2-09
V2-11
V2-13
V2-14
V3-02
V3-04
VC1-01
VC1-02
VC1-06
VEH-06
VEH-07
VEH-08
VRC-02
VRC-03
W2-09
W3-02
W06-03
W09-02
W09-04
W10-06
W10-08
W15-02
W15-03
W17-02
W18-02
W66-09
WS-02
WS-03
X2-02
X2-03
X2-05
X2-06
X4-05
X01-10
XH-04
XQ-02
XQ-03
Y1-02
Y3-03
Y3-04
Y4-03
Y7-05
ZR-05
ZT-05
Tax Percent
Number of Grace Days
Allowance or Charge Rate
Discount Percent
Usage Quantity
Other Usage Quantity
Terms Discount Amount
Vessel Registry Number
Vessel Net Registry Tonnage
Vessel Gross Registry Tonnage
Vessel Containerized Cargo Tonnage
Vessel Non-containerized Cargo Tonnage
Vessel Summer Dead Weight Tonnage
Name of Vessel Master
Length of Vessel
Sailing Date
Estimated Arrival Date
Vehicle Primary Color
Vehicle Lower Color
Vehicle Invoice Amount
Vehicle Make
Vehicle Model
Vehicle Style
Date Recovered
Vehicle Odometer Mileage
Event Date
Waybill Date
Shipment Date
Minimum Allowable Temperature
Maximum Allowable Temperature
Minimum Allowable Temperature
Maximum Allowable Temperature
Warehouse Adjustment Number
Depositor Adjustment Number
Date of Receipt
Temperature at Receipt
Charge Amount
Work Start Time
Work End Time
Import License Issue Date
Import License Expiration Date
Import License Issue Date
Import License Expiration Date
Release Issue Date
Number of Open Bills on Manifest
Charge Amount
Reporting Date/Start
Reporting End Date
Shipment Availability Date
Sailing Date
Estimated Arrival Date
Container Availability Date
Required Delivery Date
Waybill Date
Waybill Date
Page 40
Version 1.0
Preliminary Findings and Recommendations on XML-X12
Version 1.0
Appendix C — Example DTD Naming for an 850 Purchase Order
This is not a complete DTD. It is missing various pieces of XML information. However,
it does show the XML “names” that are created from the X12 syntax and semantic
databases, which is the main purpose for this DTD example. Additionally, not all of the
data elements and semantic notes have been added. We should be able to complete the
DTD with all the names programmatically derived from the X12 databases in the near
future.
<?xml version=“1.0”>
<!DOCTYPE Purchase.Order [
<!ENTITY % X12.Order.Types “
“>
<!ENTITY % Other-Details ( ?)>
<!ELEMENT Purchase.Order (PurchaseOrderHeader, PurchaseOrderDetail,
PurchaseOrderTrailer)>
<!ELEMENT PurchaseOrderHeader (TransactionSetHeader, BeginningSegment, Currency?,
ReferenceID?, AdminCommunicationsContact?, TaxReference?, FOBRelatedInstructions?,
PricingInformation?, PeriodAmount?, SalesRequirements?, Commodity?,
ServiceAllowanceChangeLOOP1?, TermsOfSaleDeferredTermsOfSale?, DiscountDetail?,
InstallmentInformation?,DateTimeReference?, LeadTime?, ItemID?,
ServiceCharacteristicsID?, ProductItemDescription?, Measurements?,Paperwork?,
MarkingPackagingLoading?, CarrierDetailQuantityAndWeight?,
CarrierDetailsRoutingSequenceTransitTime?, CarrierDetailsEquipment?,
CarrierDetailsSpecialHandlingOrHazardousMaterialsOrBoth?,
MarksAndNumbers?,PercentAmounts?, RestrictionsConditions?, TaxInformation
AmountLOOP?, Name9InformationLOOP1 1?, Name1InformationLOOP1 ?, LMLOOP1?,
SpecificationIDLOOP1?, AdvertisingInformationLOOP1?)>
<!ELEMENT PurchaseOrderDetail (BaselineItemData, ItemID?, ServiceCharacteristicID?,
Currency?, ContractInformation?, AdditionalItemDetail?, CTPLOOP1?, PeriodAmount?,
Measurements?, ProductIDLOOP1?, PaperWork?, ItemPhysicalDetails?, ReferenceID?,
AdminCommunicationsContact?, ServiceAllowanceChangeLOOP2?, ConditionsOfSale?,
SalesRequirements?, TermsOfSaleDeferredTermsOfSale?, DiscountDetail?,
InstallmentInformation?, TaxReference?, FOBRelatedInstructions?,
DestinationQuantity?, AdditionalItemData?, DateTimeReference?, Commodity?,
CarrierDetailsQuantityAndWeight?, CarrierDetailsRoutingSequenceTransitTime?,
CarrierDetailsEquipment?,
CarrierDetailsSpecialHandlingOrHazardousMaterialsOrBoth?, PercentAmounts?,
MarksAndNumbers?, MessageText?, SpecificationID?, TaxInformation?,
RestrictionsConditions?, QTYLOOP1?, SCHLOOP1?, PKGLOOP1?, LoopHeader?,
LeadTimesLOOP1?, LoopTrailer?, Name9InformationLOOP1?,
Name1InformationLOOP1?,SublineItemDetailLOOP1?, AmountLOOP2?, LMLOOP2?)>
<!ELEMENT PurchaseOrderTrailer (TransactionTotals?, MonetaryAmount?)?,
TransactionSetTrailer)>*******Subelements of Table********
<!ELEMENT AdvertisingInformationLOOP1 (AdvertisingDemographicInformation?,
DateTimeReference?, Text?)>
<!ELEMENT AmountLOOP1 (MonetaryAmount?, ReferenceID?, DateTimeReference?,
PercentAmounts?, FinancialData1LOOP1?)
<!ELEMENT AmountLOOP2 (MonetaryAmount?, ReferenceID?, PercentAmounts?)>
<!ELEMENT ContractAndCostAccountingStandardsData1LOOP1
(ContractAndCostAccountingStandardsData?, ReferenceID?, DateTimeReference?,
LeadTime?, MessageText?)>
<!ELEMENT CTPLOOP1 (PricingInformation?, Currency?)>
<!ELEMENT FinancialData1LOOP1 (TypeOfFinancialAccountingData?, AccountingData)>
<!ELEMENT LeadTimesLOOP1 (LeadTime?, Quantity?, MessageText?, ReferenceID?, LMLOOP3?)>
<!ELEMENT LeadTimesLOOP2 (LeadTime?, MarksAndNumbers?, Quantity?, MessageText?,
ReferenceID?)>
<!ELEMENT LMLOOP (CodeSourceInformation?, IndustryCode)>
<!ELEMENT LMLOOP1 (CodeSourceInformation?, IndustryCode?)>
Page 41
Preliminary Findings and Recommendations on XML-X12
Version 1.0
<!ELEMENT Name1InformationLOOP1 (Name?, AdditionalNameInformation?, AddressInformation?,
GeographicLocation?, Quantity?, LocationsIDComponent?, ReferenceID?,
AdminCommunicationsContact?, ServiceCharacteristicID?, DateTimeReference?,
FOBRelatedInstructions?, LineItemSchedule?, CarrierDetailsQuantityAndWeight?,
CarrierDetailsRoutingSequenceTransitTime?, CarrierDetailsEquipment?,
CarrierDetailsSpecialHandlingOrHazardousMaterialOrBoth?, MarkingPackagingLoading?,
LeadTimesLOOP1?)>
<!ELEMENT Name1InformationLOOP1 1 (Name?, AdditionalNameInformation?,
AddressInformation?, GeographicLocation?, LocationsIDComponent?, ReferenceID?,
AdminCommunicationsContact?, ServiceCharacteristicID?, FOBRelatedInstructions?,
CarrierDetailsQuantityAndWeight?, CarrierDetailRoutingSequenceTransitTimes?,
CarrierDetailsEquipment?,
CarrierDetailsSpecialHandlingOrHazardousMaterialsOrBoth?,
MarkingPackagingLoading?)>
<!ELEMENT Name1InformationLOOP1 3 (Name?, AdditionalNameInformation?,
AddressInformation?, GeographicLocation?, LocationIDComponent?, ReferenceID?,
AdminCommunicationsContact?, ServiceCharacteristicID?)>
<!ELEMENT Name1InformationLOOP1 4 (Name?, AddtionalNameInformation?, AddressInformation?,
GeographicLocation?, Reference Identification?, Contact?, MessageText?)>
<!ELEMENT Name9InformationLOOP1 1 (ReferenceID?, DateTimeReference?, MessageText?)>
<!ELEMENT Name9InformationLOOP1 2 (ReferenceID?, DateTimeReference?, Measurements?,
MessageText?)>
<!ELEMENT PKGLOOP1 (MarkingPackagingLoading?, Measurements?)>
<!ELEMENT ProductIDLOOP1 (ProductItemDescription?, Measurements?)>
<!ELEMENT QTYLOOP1 (Quantity?, ServiceCharacteristicID?)>
<!ELEMENT SCHLOOP1 (LineItemSchedule?, CarrierDetailsQuantityAndWeight?,
CarrierDetailsRoutingSequenceTransitTime?, CarrierDetailsEquipment?,
CarrierDetailsSpecialHandlingOrHazardousMaterialsOrBoth?, ReferenceID?)>
<!ELEMENT ServiceAllowanceChangeLOOP1
(ServicePromotionAllowanceOrChangeInformation?,Currency?)>
<!ELEMENT ServiceAllowanceChangeLOOP2 (ServicePromontionAllowanceOrChargeInformation?,
Currency?, PricingInformation?)>
<!ELEMENT SpecificationIDLOOP (SpecificatonID?, ReferenceID?, DateTimeReference?,
MessageText?, Name1InformationLOOP1 4?,
ContractAndCostAccountingStandardsData1LOOP1?)>
<!ELEMENT SublineItemDetailLOOP1 (SublineItemDetail?, MessageText?,
ServiceCharacteristicID?, ProductItemDescription?, AdditionalItemDetail?,
Commodity?, AdvertisingDemographicInformation?, DateTimeReference?,
PricingInformation?, PeriodAmount?, ItemPhysicalDetails?, TaxReference?,
Name9InformationLOOP1 1?, ServiceAllowanceChangeLOOP2?, QTYLOOP1,
Name1InformationLOOP1 3?)>
<!--********Data Element Definitions – Many yet to be completed ***************-- >
<!ELEMENT
AccountingData ( ) >
<!ELEMENT
AdditionalItemData ( ) >
<!ELEMENT
AdditionalItemDetail ( ) >
<!ELEMENT
AdditionalNameInformation ( ) >
<!ELEMENT
AddressInformation ( ) >
<!ELEMENT
AdminCommunicationsContact () >
<!ELEMENT
AdvertisingDemographicInformation ( ) >
<!ELEMENT
BaselineItemData ( ) >
<!ELEMENT
BeginningSegment (TransactionSetPurposeCode, PurchaseOrderTypeCode,
PurchaseOrderNumber, ReleaseNumber, Date, ContractNumber?, AcknowledgmentType?,
InvoiceTypeCode? ContractTypeCode?, PurchaseCategory?, SecurityLevelCode?,
TransactionTypeCode? ) >
<!ELEMENT
CarrierDetailQuantityAndWeight( ) >
<!ELEMENT
CarrierDetailRoutingSequenceTransitTimes ( ) >
<!ELEMENT
CarrierDetailsEquipment ( ) >
<!ELEMENT
CarrierDetailsSpecialHandlingOrHazardousMaterialsOrBoth ( ) >
<!ELEMENT
CodeSourceInformation ( ) >
<!ELEMENT
Commodity () >
<!ELEMENT
ConditionsOfSale ( ) >
<!ELEMENT
Contact ( ) >
<!ELEMENT
ContractAndCostAccountingStandardsData ( ) >
<!ELEMENT
ContractInformation ( ) >
<!ELEMENT
Currency (EntityIDCode, CurrencyCode, ExchangeRate, EntityIDCode,
CurrencyCode, CurrencyMarketExchangeCode, DateTimeQualifier, Date, Time,
DateTimeQualifier, Date, Time, DateTimeQualifier, Date, Time, DateTimeQualifier,
Date, Time, DateTimeQualifier, Date, Time ) >
<!ELEMENT
DateTimeReference ( ) >
<!ELEMENT
DateTime ( ) >
Page 42
Preliminary Findings and Recommendations on XML-X12
Version 1.0
<!ELEMENT
DestinationQuantity ( ) >
<!ELEMENT
DiscountDetail () >
<!ELEMENT
FOBRelatedInstructions () >
<!ELEMENT
GeographicLocation ( ) >
<!ELEMENT
IndustryCode ( ) >
<!ELEMENT
InstallmentInformation ( ) >
<!ELEMENT
ItemID ( ) >
<!ELEMENT
ItemPhysicalDetails ( ) >
<!ELEMENT
LeadTime ( ) >
<!ELEMENT
LineItemSchedule ( ) >
<!ELEMENT
LocationIDComponent ( ) >
<!ELEMENT
MarkingPackagingLoading ( ) >
<!ELEMENT
MarksAndNumbers ( ) >
<!ELEMENT
Measurements ( ) >
<!ELEMENT
MessageText ( ) > ) >>
<!ELEMENT
MonetaryAmount ( ) >
<!ELEMENT
Name ( ) >
<!ELEMENT
PaperWork ( ) >
<!ELEMENT
PeriodAmounts (673, 380, Co01, 522, 782 344, 374, 373, 337, 374, 373, 337,
1004, 954, 1073 ) >
<!ELEMENT
PricingInformation (687, 236, 212, 380, co01, 648, 649, 782, 639, 499, 289 )
>
<!ELEMENT
ProductItemDescription ( ) >
<!ELEMENT
Quantity ( ) >
<!ELEMENT
ReferenceID (128, 127, 352, co40 ) >
<!ELEMENT
RestrictionsConditions ( ) >
<!ELEMENT
ReferenceIdentification ( ) >
<!ELEMENT
SalesRequirements (563, 306, 610, 508, 373, 559, 560, 566, 954, 1004 ) >
<!ELEMENT
ServiceCharacteristicsID ( ) >
<!ELEMENT
ServicePromotionAllowanceOrChargeInformation (248, 1300, 559, 1301, 610, 378,
332, 118, 355, 380, 380, 331, 127, 770, 352, 819 ) >
<!ELEMENT
SpecificationID ( ) >
<!ELEMENT
SublineItemDetail ( ) >
<!ELEMENT
TaxInformation ( ) >
<!ELEMENT
TaxReference (325, 309, 310, 309, 310, 309, 310, 309, 310, 309, 310, 441,
1179 ) >
<!ELEMENT
TermsOfSaleDeferredTermsOfSale (336, 333, 338, 370, 351, 446, 386, 362, 388,
389, 342, 352, 765, 107, 954 ) >
<!ELEMENT
TransactionSetHeader (TransactionSetIDCode, TransactionSetControlNumber ) >
<!ELEMENT
TransactionSetTrailer ) >>
<!ELEMENT
TransactionTotals ( ) >
<!ELEMENT
TypeOfFinancialAccountingData ( ) >
]>
Page 43
Preliminary Findings and Recommendations on XML-X12
Version 1.0
Appendix D — Scenario
In this scenario, XML/EDI is used with an IETM, an Interactive Electronic Technical
Manual, to send information.
A technician repairing an airplane has his electronic technical manual. The technical
manual internal data representation is already formatted in SGML (state of the art today).
The IETM contains information about the technician, his skill level, his training level,
etc. It also contains information about the piece of equipment he is repairing, i.e., what
type of airplane, model number, equipment configuration, etc.
The technician finds the problem — the plane has a defective ‘whatjamacallit.’ The
IETM indicates to the technician that he needs a new ‘whatjamacallit.’
The technician, from his IETM, asks the logistics system, “Do you have a
‘whatjamacallit’ in-stock?” The IETM does not transfer all the data about the technician
or the airplane or the maintenance procedures to the stockroom. It transfers only the
necessary information required to see if the ‘whatjamacallit’ is in stock: model number,
cage number, and possibly the technician’s ID to see if he has the authority to request that
part.
The logistics system indicates the part is not in stock and must be ordered. The ordering
process begins and is sent directly to the person who has authority to approve the order.
Again more information can be sent to the approval person, such as what the diagnostic
error was that required the part to be ordered. A person can digest this information, but
the stockroom does not care.
The order is sent directly to the vendor.
In this simple scenario, in all phases of the process different information is being
captured and sent. However, XML allows the data format through the entire workflow
process to be transferred in one standard format.
The same scenario above can be used in all types of situations, not just maintenance.
Patient care in hospitals would also be a good example.
Page 44
Preliminary Findings and Recommendations on XML-X12
Version 1.0
Appendix E — Sample Programming for XML Interactions
This example is not related to the previously discussed use cases or scenarios. It was
provided to demonstrate how today’s mainstream programming tools can potentially
approach a programmatic solution. It was felt that some kind of illustrative example was
required to show the level of effort this might entail for programmers to physically
implement an X12 XML based data interchange.
The following is Visual Basic (VB) code that would take an order ID from an HTTP
stream and return the contents of the order to the calling application in XML format.
This code could be executed in the memory space of the Web Server as ASP code or the
code could operate in a business object called by the Web server.
Dim xmlstring
Dim rs As New ADODB.Recordset
Dim sql
Dim OrderID
OrderID = Request(“OrderID”)
sql = “SELECT * FROM Orders WHERE Order_ID = “ & OrderID
rs.Open sql, ActiveConnection,adOpenDynamic ,adLockBatchOptimistic
If Not rs.Eof Then
xmlstring = rs.GetString (adXMLString)
Response.write xmlstring
End If
Note that just because it is a Web server that is hosting this code and the transport is
HTTP, does not mean that the client always has to be a browser. The above code could be
displayed by any browser supporting Dynamic HTML, or it could also be called by a
client application that was programmed to communicate via HTTP. The beauty of this is
that it only has to be coded once, and both types of access are supported.
Note also that the Microsoft™ ActiveX Data Objects 2.0 Library™ currently supports
“Recordset.GetString (adXMLString)” in documentation only. In other words, the
functionality is documented but does not work as of today. A temporary work-around can
be created by creating a class that performs the same function.
Page 45
Preliminary Findings and Recommendations on XML-X12
Version 1.0
Included below is a snippet of code that shows how to loop through a record outputting
XML.
Dim f As ADODB.Field
For Each f In rs.Fields
Response.write “<“ & f.Name & “>“ & f.Value & “</” & f.Name &
>“
Next
Here is some code to read this in a browser that supports Dynamic HTML
<OBJECT ID=“Orders” CLASSID=“clsid:333C7BC4-460F-11D0-BC04-080C7055A83”
WIDTH=0 HEIGHT=0>
<PARAM NAME=“DataURL” VALUE=“www.getorder.com?OrderID=1234”>
</OBJECT>
<TABLE DATASRC=“#Orders” BORDER=1>
<THEAD>
<TR>
<TH>
<DIV> Order ID </DIV>
</TH>
</TR>
</THEAD>
<TBODY>
<TD>
<INPUT TYPE=TEXT DATAFLD=“Order_ID” SIZE=20>
</TD>
<TD>
<INPUT TYPE=TEXT DATAFLD=“Cust_ID” SIZE=20>
</TD> </TBODY>
</TABLE>
Page 46
Preliminary Findings and Recommendations on XML-X12
Version 1.0
An SME programmer would only have to write the following lines of code to get an
order.
Dim order as OrderObject
Dim rs As New ADODB.Recordset
order.ID = 1234
order.URL = “www.getorder.com”
Set rs = order.GetRS()
This assumes that the order object encapsulates the communication and conversion of the
XML back to a recordset. This functionality is what Microsoft™, Powersoft™,
CommerceNet™, Oracle™, and any number of other vendors are talking about when
they talk about XML. But even if these players failed to live up to their hype, the
implementation of this code is trivial compared to implementing X12 or EDIFACT in an
organization.
Page 47
Preliminary Findings and Recommendations on XML-X12
Version 1.0
An example, in pseudo-code, for simple parsing of an XML message follows:
loop()
read_line()
line_loop()
find_next(‘<‘)
extract_token_name(),
extract_token_value(Value,no_value,close_level),
if ( no_value, (bump_nesting_level)),
else
call old_Ascii_routine(Next_field,Value)
endif
if (close_level)
call old_ascii_routine(nesting_level),
decrement_next_level
endif
end_line
end_loop
The logic presented here is designed to provide a non-validating parser of XML that can
replace logic in an existing ASCII delimited parser typically used to process the output
from a traditional EDI translator into a database.
The idea is to provide a front-end that can interpret the XML and then pass the value
details to the original ASCII parsing logic as if it had been read from a traditional ASCII
source.
Page 48
Preliminary Findings and Recommendations on XML-X12
Version 1.0
Appendix F — Example Use Case
Based on the principles established in Section 13 on creating X12 DTDs for XML we can
now see how these techniques can be applied to an actual scenario.
The objective here is to present a typical scenario using XML in combination with X12,
one that involves both a simple Web-enabled end user as well as a traditional EDI VAN
service.
Figure 1 illustrates the actual scenario and is then followed by a description of the steps
required to implement X12 XML as software components and processes.
F.1. Describing the Scenario
The scenario starts with a typical E-Commerce HTML-based system that is being
upgraded to use EDI and XML interactions.
In this example, we are tasked with quickly and easily integrating to the existing ECommerce Web site and any application database store. A prime requirement is for
minimal code changes for these existing applications.
The second requirement is to provide a means to send X12-compliant purchase orders to
SMEs who have no X12 translator, VAN service or other means available, only a Web
browser, a PC and a dial-up connection.
Page 49
Preliminary Findings and Recommendations on XML-X12
Figure 1 — Flow of information for XML-X12 example
Page 50
Version 1.0
Preliminary Findings and Recommendations on XML-X12
Version 1.0
F.2. Step 1 — The Output from the E-Commerce System is Received in XML Format
The existing E-commerce system gets the order details from the customer: their account
number, items to be ordered, delivery requirements. This information back-ends into an
accounting package, so not all the data comes from the Web. A lot of it is in the
accounting system.
First we convert the old HTML output from the E-commerce system to XML. This step
will of course use XML tag names derived from what the programmers were doing with
the HTML. We do not care at this point; they can call things whatever is quick and easy
for them. More importantly, these names will reflect their own business domain, so the
generic EDI name ‘Part Number,’ in their system is called ‘VCI Number’ for ‘Vehicle
Component Item,’ and so on.
Now we have our initial XML output, we map this to X12 by providing a DTD that
explicitly identifies in the DTD attributes which fields map to which X12 elements. (See
Tables 2a and 2b for how to look up valid UNIQUE ID numbers that map to the actual
X12 elements.) At this point, we may also need to provide a quick XSL script to reformat
the original Web-based XML into something better for X12, and or just attach the DTD
to the message (see http://www.microsoft.com/xml/xsl for full discussion of functionality
of XSL and examples).
F.3. Step 2 — Additional Information is Now Required for EDI Compliance
To complete all the details required for a valid X12 interaction, we need to add to the
XML information from Step 1.
Read output from Step 1 into the application program. Get Customer Number, Part
Number, and so on. Look these up in our accounting database, and get all the ancillary
information needed to fully populate the X12 database. Again these are simple SQL
SELECT statements that return XML directly, or write your own very simple XML
generator code based off the field names in your database. (Note: This document is NOT
a tutorial in XML extracts. This step can be done by programmers who know how, and/or
by several commercially available tools.)
As in Step 1, we need to take the output here and create a combined DTD for the whole
transaction. Again XSL provides a quick means to get there, and again the new fields are
identified by attributes in the DTD. Notice that we have not forced any design changes on
the database, or forced people to use field names they do not like.
F.4. Step 3 — The Delivery Phase
Now we are ready to ship out the whole transaction. Some suppliers get the total XML
and DTD as is. This they can either use with their own XSL script (or similar technique)
to view in their Web browser or the default script we provide to them. Notice that we can
add “Submit” buttons to the resultant HTML forms generated by the scripts to send the
answers directly back to our Web server and order-processing system.
Alternatively, we can also send the XML to a traditional VAN service that is X12 XML
compliant. When the VAN service gets it, they will morph the XML into an X12
transaction using the mapping DTD that explicitly tells them how to do this (because it
Page 51
Preliminary Findings and Recommendations on XML-X12
Version 1.0
identifies the exact one-to-one correlation between the XML tag names and the X12
elements).
This use case looks only at this send scenario.
Page 52