TranXML

XML Vocabulary for the Transportation and Logistics Industry

Introduction

Executive Summary

XML technology represents the most versatile and robust format for exchanging business information since the development of open EDI standards. In the last two years corporate entities, vertical industry groups and trade portals have realized the benefits of XML. In response, many have embarked on a fast-track development effort to establish XML as their preferred format for Business to Business Exchanges (B2B) and Enterprise Application Integration (EAI).

Most of the development efforts have centered on vertical industry implementations for B2B exchanges. Efforts such as RosettaNet and ChemXML are specifically geared to the supply chain needs of their respective industries. The business process models, semantic vocabularies and message functions directly reflect the business practices found in a specific environment. Due to this development methodology, vertical industries are creating collaborative XML dictionaries that can only facilitate a one-to-many trading partner relationship. This relationship is limited to the community within that vertical industry. A many-to-many relationship cannot be achieved until a new XML open standard is adopted.

The Transportation and Logistics industry, however, cuts across all vertical boundaries. It must serve many masters, such as Chemicals, Electronics, Utility, Automotive and others. As vertical industries are developing their own collaborative vocabularies, Transportation is forced to adopt (and support) all of the flavors created by the industry standards. Additionally, the semantic definition of transport and logistic objects may not be appropriate, as some of the industry groups lack the domain knowledge to develop meaningful vocabularies to support logistics functions. It is for this reason that Transentric has developed TranXML, which can be used as the common vocabulary to support logistics supply chain functions across vertical collaborative vocabularies.

 

 

 

 

 

TranXML

Semantic Definitions - Leveraging EDI Formats

The largest obstacle to data exchange is the lack of common semantic structures and repositories supporting the flow of data to and from disparate applications. For instance, in the supply chain, a 'Buyer' could be considered as a 'Consignee.' And a 'Seller' could be considered as a 'Shipper.' This is dependent on whether the information is coming from a purchasing or logistics system. This difference in semantic definitions used by different systems (and industries) has hindered the expanded use of data exchange.

The robust nature of XML technology can further complicate data exchange by allowing developers to create their own sets of semantic definitions for each application. The proliferation of tag names and structures further hinders interoperability and forces developers to create more maps between applications and formats. This not only makes it difficult to exchange data between internal applications, but also makes it nearly impossible to effectively exchange data with external trading partners.

Open-standard EDI formats such a X12 and EDIFACT have come the closest to establishing common semantic repositories for global data exchange. Since these data formats and content are commonly understood by many users, it makes sense to adopt existing dictionaries as a basis for XML development. This is particularly important in the transportation and logistics industry, where carriers have been using these formats to exchange data for over 25 years.

Such open standard EDI has provided the basis of e-commerce for many years, and remains today the backbone of information exchange. Although EDI has been transformed to take advantage of new Internet and communications technologies, the dictionaries remain virtually unchanged.

EDI standards represent a stable and effective method of information exchange as they have been developed in a collaborative environment, ensuring the highest level of interoperability. Unfortunately, traditional EDI formats are not 'approachable' by application developers. This means that the data is tied to a physical structure defined by the EDI format, and has no semantic meaning on its own. This severely restricts the use of common objects. Additionally, it is difficult for developers to understand, as it is not in a human readable format.

The challenge is now to leverage the semantic content of open-standards based EDI in order to create meaningful and approachable XML structures.

TranXML Objectives

TranXML provides a standardized set of XML structures that will foster the flow of information between various internal and external applications. It will allow for the optimization of data structures to ensure interoperability, which are based on existing EDI formats. Additionally, it allows for a format that is both human and machine readable, allowing for greater flexibility than traditional EDI.

Transentric will employ XEDI as the initial transformation tool from EDI to meaningful XML objects. XEDI is simply a human readable representation of EDI. The machine-readable EDI element codes become the attributes of the XML-EDI objects, and the human readable meaning for the attribute is maintained in the contents of the XML elements. By using this approach, the semantic integrity, as well as the validation capabilities of the EDI is maintained. Furthermore, the meaning and purpose of data in the XML object is easily interpreted without having to refer to an EDI standards manual. By giving programmers both existing semantics and new XML syntax, the approach allows EDI programmers to leverage that they have used for the last twenty years.

Although XEDI offers users the wealth of common semantics contained in the X12 and EDIFACT dictionaries, it is restrictive in its ability to create common structures as it maintains the structural integrity of the EDI. This limits the interoperability of the objects, as all elements are tied to the higher-level structures on the segment and message levels.

TranXML is an attempt to transform the foundation of knowledge contained in XEDI into a more approachable - and interoperable - format. To that extent, TranXML applies business rules for the transformation of XEDI data into objects that can be used by many disparate applications. Transentric's wealth of experience in logistics and transportation will be used as a basis for the creation of the transformation rules. The new core components will create a common XML data dictionary that can be used for both internal and external applications.

The following diagram illustrates the transformation process:

TranXML Development

Internal Applications

It is envisioned that TranXML will first be used to create XML structures for internal Transentric applications. The first application will be to provide common semantic structures for message conversions relating to tracing and load tenders. Below is a list of schemas that have been developed and used to populate the TranXML data dictionary:

By applying specified transformation rules, there needs to be only one map from the TranXML for all of the applications that are populated by the messages named above. The common objects will greatly reduce all of the Application Data Interface (ADI) programs and formats needed to integrate the data. Transentric plans to migrate all legacy systems and develop new systems utilizing the TranXML Dictionary in order to reduce internal ADI maintenance.

To ensure that the TranXML dictionary is as interoperable as possible, Transentric draws upon internal domain knowledge as well as standards established by other authorities such as ChemXML, RosettaNet and ebXML. As of this writing, the only logistics messages developed in an open standard environment have been within the auspices of CIDX and Bolero. TranXML will draw upon their experience to ensure that it will be as interoperable with those external trading partners.

Standards

Given the absence of global tagging standards, corporate entities, vendors, ASP's and industry groups are free to develop their own schema and semantic definitions. Various bodies are developing standards for use in vertical markets. Other bodies are taking a more global approach to standards development, using cross-industry collaboration. Some of the standards groups are listed below:

Develops and maintains a collaborative dictionary based on the business practices of the electronics industry. The dictionary and tag names are copyrighted by RosettaNet. The collaborative dictionary and resulting schema are specific to that industry with a supply chain focus. Schema supporting logistics and carrier functions are not heavily supported.

The ChemXML effort is also a collaborative dictionary based on the RosettaNet standards. The Phase II dictionary and schema, released in January 2001, support the logistics and transportation functions. This standards is developed, maintained and copyrighted by CIDX and represents a collaborative effort of Chemical Manufacturers and their trading partners.

A private trading partner community facilitated and maintained for Microsoft. Supports the BizTalk framework, which supports all levels of trading partner communications and application integration

The United Nations body for Trade Facilitation and Electronic Business (UN/CEFACT) and the Organization for the Advancement of Structured Information Standards (OASIS) have joined forces to initiate a worldwide project to standardize XML business specifications. UN/CEFACT and OASIS have established the Electronic Business XML initiative to develop a technical framework that will enable XML to be utilized in a consistent manner for the exchange of all electronic business data. Industry groups currently working on XML specifications are participating in the 18-month project. A primary objective of ebXML is to lower the barrier of entry to electronic business in order to facilitate trade, particularly with respect to small- and medium-sized enterprises (SMEs) and developing nations. The Core Components group is developing recommendations for the creation of semantic objects based on standard EDI.

Collaborative Efforts?

Although the standards bodies above represent collaborative efforts, many of them are still based on the business practices and semantic objects of a particular vertical industry. However, if one looks at large-scale collaborative efforts supporting e-commerce, they will find that the X12 and EDIFACT dictionaries represent the largest collaborative repository of information in the world.

Given this fact, TranXML is based upon that collaborative effort and draws the semantic meaning of the XML objects directly from the open-standards dictionaries. In the future, Transentric will work with other development groups to incorporate the needs of other trading partners.

 

TXML Structure

Transentric applied a set of transformation rules to develop the TranXML core components, structures and elements. It is important to note that we must carefully distinguish between what data can or can not be automated by these rules. Structures that can not be automated are called core components, and must be developed using domain knowledge. the general rules may be applied across multiple messages and applications. However, when new messages are transformed, new rules may have to be defined.

Transentric has developed an XSLT to automate the transformation process. The data element definitions and segment names are transformed into XML tags. This will provide approximately 80% of the transformation from EDI to TranXML. The other 20% must be evaluated and manually added to the dictionary.

Why Schema instead of DTD?

TranXML is based on Schema rather than existing DTD definitions because of the capability to include metadata within the defined elements. The main benefit is that Schema allow compliance checking and retain much of the robust syntax validation currently afforded by traditional EDI.

The current W3C Candidate Recommendation for XML Schema (XSD) allows elements to be given constraining facets. DTDs do not support this functionality. Nor do they support data typing, field length restrictions and other validation tools employed in a Schema. TranXML makes use of attributes with enumerated code lists based on the EDI dictionary. Additionally, the Schema can reflect the any restrictions currently established in EDI. In anticipation of the Candidate Schema becoming approved, TranXML is designed to take advantage of the more robust capabilities, without the constraints of the inadequacies of DTDs.

Schema and Structural Components

Below is a diagram of the TranXML components:

 

 

The main dictionary contains one schema housing the TranXML semantic repository. It contains all elements, structures (similar to segments) and core components (generic structures). This will provide the building blocks for specific schema development.

Each message type can then be defined with a 'Group Schema'. This schema will 'include' the objects and core components from the TranXML dictionary, which can be grouped according to the developer's specification. For instance, developers can build groupings of objects to conform to different EDI versions, applications or business needs.

The message schema will include both the group and dictionary objects, and will specify the ordinal position definitions of all objects contained within the message. This will give developers a greater amount of flexibility in designing new message types to suit their business needs. As the messages are based on the common objects contained in the TranXML repository, the various message types will be consistent on an ADI level.

Transformation Rules

Tag Naming Conventions

An essential part of the XML grammar is consistent naming conventions for tags that represent the infrastructure and business-related elements. The TranXML Tag name is made from the XEDI description value. Tag names shall conform to the Transentric tag-naming conventions as given below:

Example: <ShipmentMethodOfPayment>

Example: <SPLC>

Example: <AddressPO_Box>

Tag Suffix Names

Data in an EDI document exists at many levels – these are Transaction, Loop, Segments and Elements. Because only element numbers are guaranteed to be unique in the X12 standards, when we use the X12 descriptions, the same tag name could exist multiple times in a document but depending on its placement will mean different things. While the argument could be made that it is desirable to create "level" suffixes for the purposes of preventing confusion, extra suffix names at every level have been found to add clutter to the document and limit readability.

Attributes

Attributes are used to further qualify an element. The general rule of XML message creation is that data should be stored in elements, and information about the data (Metadata) should be stored in attributes. TranXML defines two types of attributes to be added to elements. These attributes are Qualifiers and optional SegmentID.

Qualifier Attributes are derived from ID type data elements as defined in EDI. These are usually structurally related to the qualified entity in a paired relationship in the EDI structures. As automated transformation takes place based on the element definitions (in human readable format) we can identify those elements which are to become attributes. According to the ASC X12 Design Rules and guidelines, ID type data elements shall contain either word 'Qualifier' or 'Code'. We can use this as a key to determine if an element should become an attribute of another.

SegmentID Attributes are optional and are to help developers with standards-based EDI knowledge. Each segment is given a description attribute that gives the EDI definition of the segment.

Structures

When creating the TranXML dictionary, items that describe the same "object" should have a parent structure created for that object. The object can then be interoperable among many applications and/or message types. For instance, <Name> can be used within multiple parent structures, such as <Shipper>, <Consignee>, etc.

Examples of Structure Creation:

Consider the following XEDI representation of the N1 Segment:

<Name SegmentId="N1">

<EntityIdentifierCode/>

<NameData/>

<EntityIdentifierCode Qualifier=""/>

<EntityRelationshipCode/>

<EntityIdentifierCode/>

</Name>

The transformed structure will look like the following:

Core Components

Core Components are the basis for the TranXML data dictionary, as they will provide the interoperability between applications. These structures provide the bridge between structural EDI objects and approachable semantic objects. In specific cases, Transentric has applied domain and logistics knowledge to create these structures that customers and application developers are more able to identify.

The N1 looping structure in X12 provides a good example of the creation of a core component. Given the code value within the attribute attached to <NAME>, we can create core components, which are commonly used within the transportation and logistics domain. Some examples are <Shipper>, <Consignee>, <ShipTo>, etc. TranXML uses the common objects to create the core component.

Other core components have been created for Identification numbers, equipment identification, Date/Time and Measurements.

Conclusion

Drawing on the robust collaborative effort in developing open-standard EDI, TranXML has the ability to provide a common semantic repository that cuts across vertical vocabularies. Although developed for in-house Transentric applications, TranXML can enable multiple trading partners to exchange business data with less ADI maintenance and development.

It is envisioned that transportation entities and their trading partners will endorse the TranXML repository and will soon be developing messages and structures to support their electronic commerce needs.

TranXML provides the perfect complement to companies who have already implemented EDI, and a perfect solution to those who are now developing XML solutions for their transportation data exchange.