XML: What it is & why it matters

XML organizes data and contains instructions for understanding that organization. XML can present data so it can be read by a person or by a computer. Let's admit right from the start that everything about XML defies normal expectations. It's a computer standard that functions quite well without universal agreement on its exact components. It's perfect for exchanging electronic documents between trading

XML organizes data and contains instructions for understanding that organization.

XML can present data so it can be read by a person or by a computer.

Let's admit right from the start that everything about XML defies normal expectations. It's a computer standard that functions quite well without universal agreement on its exact components. It's perfect for exchanging electronic documents between trading partners, but it's also perfect for integrating applications running on different operating systems or hardware.

Even the acronym XML isn't exactly what it seems. It stands for “Extensible Markup Language,” but apparently EML just wasn't catchy enough for the technocrats who named it.

It's worth the effort to try and understand this new computer technology because it offers trucking major benefits that will quickly make it the industry standard for all kinds of information technology uses.

Its promises include simplified e-commerce with customers and suppliers, more powerful mobile computer systems at lower costs, and faster, more practical integration of fleet and enterprise information systems — even if they're running on different operating platforms.

The first step in understanding the value of XML is to understand its most basic function: it's a method for organizing and describing data in a text document. In essence, it presents data so it can be read by a person or a computer. It accomplishes this through the use of “tags” that “mark up” or identify a specific role or function for data.

If you've ever looked at the code behind a web page, you've seen information tagged in Hyper Text Markup Language (HTML). Your web browser uses the tags to translate a bunch of type into the graphic web page you see. For example, a tag such as

tells your web browser that the words following it should be displayed as a headline.

The important difference between HTML and XML is that HTML tags are carefully defined by standards groups and can only be interpreted by a web browser if they are followed precisely. “Extensible” (the X in XML) means the tags or data markers can be extended without limits by any user. This gives XML incredible flexibility, as well as the ability to quickly adapt to new uses. A program receiving an XML document can correctly interpret tags it has never seen before because each XML document includes a dictionary defining its tags.

To recap, XML organizes data and contains instructions for understanding that organization.

Before we can move on to practical examples of how it will benefit trucking, there are two more important characteristics of XML that need to be explained.

First, it can run on any platform with applications written in any computer language. This means you can trade documents with customers or internal departments running applications on mainframes, UNIX or Windows systems without creating complex interfaces.

Secondly, a single XML document can be used in a spreadsheet, displayed as a document, fed into an enterprise system, or faxed.

XML can thus be used to link older systems and applications within a fleet without large investments in new technology, as well as to communicate electronic documents with trading partners without expensive or complex EDI (electronic document interchange) systems. It also has important implications for closely integrating new handheld and mobile computers with back office systems.

The most obvious use for XML in trucking is as a replacement for EDI. It's also the most controversial.

Generally, fleets have adopted EDI systems because large shippers demand it. Although it follows a well-defined set of standards, in practice, establishing EDI communications requires careful coordination between fleets and each of their EDI trading partners. Both parties must agree on what data is included and where it is placed.

In addition to the cost of developing these separate EDI templates, there's a cost for each EDI transmission over secure third-party data networks. The combination of cost and complexity has effectively limited EDI to large fleets and their large shippers.


In theory, XML eliminates, or at least minimizes, the cost and complexity of trading documents electronically. XML documents can be created with off-the-shelf software, and interfaces or translation pieces needed by shippers to use them can be created relatively easily.

ClickLogistics (www.clicklogistics.com) is an Internet-based shipment management service for shippers and carriers. Recently it signed up a major new shipper for its load-tendering services. “It took us three weeks to develop the XML format for sending us their loads,” says Michael Dieter, CTO. “It would have taken twice as long with EDI.”

Not only was ClickLogistics able to use off-the-shelf software to build XML documents for that shipper's existing information system, it also avoids EDI's per-transaction costs since XML is designed for secure transmission over the Internet.

Some fleets, especially those that have made large investments in EDI and see it as a competitive advantage over fleets that can't afford it, maintain that XML isn't a suitable replacement — at least not yet. A lack of industry-specific standards means that one shipper might use the tag and another

and yet another to indicate the same type of information.

This lack of standards for describing common data, the critics say, severely limits XML's usefulness for electronic data exchanges.

But supporters say that since XML documents contain dictionaries that define their individual structure, it should be fairly easy for those receiving them to identify the information needed.

Numerous organizations are already working to “define these dictionaries for how their industry will describe data,” says Andy Yeomans, vp-sales and marketing for Subject, Wills and Co. (www.swc.com), a developer of e-business applications.

“Industry standards will take time to evolve,” says John Matranga, director of XMLabs (www.xmlabs.net). But even with industry standards in place, fleets will always be asked “to develop specialized documents for some customers,” he says. “A large amount of EDI's cost comes from developing those specialized agreements, but by design XML allows for easy extension of existing documents on an agreement-by-agreement basis.”


Those standards are likely to be developed by various vertical industries and pushed down to fleets looking for their freight. “Shipment information requirements for each shipper community will be set individually,” says Matranga. “XML will allow fleets to deal with all those varieties without the cost of specialized EDI transfers.”

As for large shippers that insist on EDI because of their own investments in that technology, some software companies have developed “bridges” that allow EDI and XML to be interchanged seamlessly, says Yeomans.


While XML has initially been promoted as a tool for e-commerce, its greatest potential may be as an easy, inexpensive technology for integrating a wide variety of computer platforms and the many applications currently running in isolation on those platforms.

One of the first industry suppliers to take advantage of that capability is onboard computer maker Cadec Corp. (www.cadeccorp.com). The latest version of the company's fleet management application uses XML to ease data transfers between a fleet's corporate ERP (enterprise resource planning) system, the fleet management application and Cadec's new Mobius TTS onboard computer, which may also include a handheld data collection unit.

The fleet management portion runs on a Windows 2000 server and rests on an SQL Server database. The onboard portion of the system runs under the portable device operating system Windows CE. The enterprise systems might run under a variety of operating systems, including UNIX, and databases such as Oracle.

In the past, Cadec customers would generate routes with their enterprise systems and export that data in one of several standard formats, says Bruce Olsen, the company's chief technical adviser. “We had to write a customized interface to get the information out of the customer's system and into ours,” he says. Information collected by the driver had to follow a reverse path through the interface and back into the enterprise system.

With XML, the enterprise system can now generate a single XML file with both route and delivery information, which is then transferred to the Cadec office application. The delivery detail portion of that file is then passed on in XML to the truck's onboard computer. “In reality, we're generating a single XML file with the enterprise system; both the office (application) and the truck look at that file and pick out the … data they need,” Olsen explains.

“As the driver accumulates information throughout the route, the truck onboard computer generates an XML document that goes to the office, which grabs the route information. Then the other business data is passed on to the enterprise systems,” he says.

“Nobody makes a standardized system for that type of integration,” Olsen says. “XML makes it brilliantly easy to translate so it's just like having a common platform.”

Combining wireless data service and Internet delivery of fleet management systems, @Road (www.atroad.com) has always supported open architecture approaches to data integration. “For us, XML is a standard, efficient way to move data from one application to another without having to change either of them,” says CIO Tom Allen.

Today, all of @Road's APIs (application protocol interfaces) for integrating its data with various applications is XML based. “If one of our partners wants to integrate an accounting program or fuel-tax reporting program with our location information, we'll put in an XML structure to exchange that data,” says Allen.

Not only does that make it simpler to interface existing applications, but it also opens up new uses for the data, he adds. “For example, we receive a stream of location information about vehicles (in our system),” he says. “Right now, customers use XML to take a snapshot of that database. However, we could stream it to them in real time if they wanted just by tagging (the location information) with XML and publishing the format structure.”

If the benefits sound like an irrefutable argument in favor of XML, you're not alone. “Eighteen months ago I was doing EDI with multiple carriers, and everyone predicted XML was a long way off,” says ClickLogistics' Dieter. “Today, everyone is working on an XML strategy.”

On the applications side, the move to XML has also quickly gathered speed. “Moving forward, I expect almost every software system built to use or leverage XML in some way, especially when it involves integrating various devices within systems,” says Matranga.


“Now is the time to start migrating,” adds Dieter, “Developers and computer makers are building their infrastructures using XML. EDI users are moving to XML. The reason? Better technology allows you to transmit data faster and better.”

So you're sold on the value of XML — but how do you begin to exploit that potential value? “If you're implementing brand new systems, use XML where you can,” suggests Yeomans. “It will save you money, and simplify the integration tasks.” If you or your customers must continue to support legacy EDI systems, “use technologies … that bridge the old and the new,” he adds.

And if you don't currently have the technical or financial resources to make the move right now, you should still learn all you can as it evolves since it's a good bet XML is going to be part of your future.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.