article_115_tnail

The ABCs of XML: Part I

June 12, 2006
This three-part series for CONTROL introduces readers to the basic rules of XML, its terminology and related standards, and discusses what you’ll need to know to survive in the world of connected data.
THE PROJECT was nearly finished. The end was in sight after an incredible effort of long hours, weekends, battles, changes, and all of the normal challenges that accompany a large project. We had delivered roughly 80% of the automation software for a life sciences S88 batching application when a problem surfaced – a big problem. Equipment modules and phases included commands to devices that could cross controller boundaries. 

The code construct employed for these commands were non-deterministic when crossing controller boundaries – by design. This meant that the destination may not receive the command. The problem appeared sporadically but rarely on our development system and we could never recreate the issue in a controlled environment. On a large plant-wide system with large IO bus networks, the problem was suddenly pervasive.

The code had to be changed. To change one instance was simple enough but we didn't know how many instances existed throughout the nearly 2,000 phases and equipment modules each containing many steps which in turn contain multiple actions. My initial ballpark estimate to manually modify and validate the changes was between one and two manyears. Of course the project didn't have money or time burning a hole in its proverbial pocket nor were qualified resources available to do the work. 

A few years earlier this would have been a disaster for everyone involved. A few years earlier, we didn't know what was possible with XML and XSLT. 

SAMPLE FILES >> DV SampleOnce we understood the problem and the required code changes, we knew that only XSLT could help us make the necessary code modifications with minimal project impact. We created an XSLT transform to find every action with the faulty code construct, modify the code appropriately, and record each code modification in a change log file. The code was exported from the DCS system as structured text, converted to XML, transformed with XSLT to fix the problems, converted back to structured text, and imported back into the system. The XSLT transform was validated so that each change did not have to be individually tested. All of the changes were completed with less than a man-month of work, and no impact to schedule, and minimal budget impact. 

Many in the world of automation have not bothered to learn about XML (eXtensible Markup Language) or XSLT (eXtensible Stylesheet Language Transformation) believing they are technologies for web developers, IT personnel, and consultants. The truth is that XML and XSLT are finding their way into nearly aspect of computer technology today. XML based technology has spread so pervasively and so widely across application domains that many are unaware of its impact in their own discipline or of the potential value it brings.

This four part article will introduce the basics of XML, introduce XSLT as a query and transformation language for XML data, and provide examples of how these technologies can be used in the world of automation. The three parts to follow are summarized below:

Introduction to XML
XML is a flexible general purpose data storage structure in human readable text format. Despite its name, XML is not really a "language" like HTML. Instead, XML provides a set of rules for anyone to create their own markup language. Anyone familiar with HTML will recognize many similarities with XML. These similarities made it easy for web developers to jump aboard the XML bandwagon. Its proliferation on the web has created some misconception of XML as a web-only technology. In fact Dictionary.com defines XML as: "A metalanguage written in SGML that allows one to design a markup language, used to allow for the easy interchange of documents on the World Wide Web."

However, XML has been used for much more than the easy interchange of documents on the web. so, a more appropriate definition might read: "A metalanguage written in SGML that allows one to design a markup language, used to allow for the easy interchange of data."

In this series, I'll introduce the basic rules of XML, terminology, and related standards. You'll learn how to read XML documents and how to create your own. The series will also discuss declarations, processing instructions, namespaces, well-formedness, validity, DTDs, schemas, and encoding. Finally, I'll point you to a number of resources and applications to help you learn more about XML and to help you work with your own XML documents.

XML Revealed
Here's an example of what SML actually looks like, and as seen in an XML reader called XML Notepad (See Figute 1 below):

-    XMLSchema-instance” SchemaVersion=”3516”>FEED_OP-

 
    
\\BatchServer\BATCHCTL\AreaModel\RECIPES\AMCASCON.CFG
  
2006-02-27T09:40:33
  JTSever
 
- -
  DRAIN:1  
DRAIN  
UNIT500
 
-
  FEED:1  
FEED  
UNIT500
 
FIGURE 1: XML READER
This tool takes the raw XML and translates it into an easy-to-read table.

Introduction to XSLT
I recently overheard the following conversation between two automation engineers: 

"They want to review the recipes."
"How do they want them?"
"Can you print them out?"
"That'll take a few days."
"Can you export them?"
"I can save them as XML."
"What do I do with that?"
"I don't know."

I'm not sure how this problem was resolved because I couldn't stick around to help them out. Had either of them known about XSLT, they could have transformed those XML recipes into any number of formats. The easiest of these would have been a CSV that could be opened in Excel. Another option (my favorite) would be to transform the recipes into MS Visio drawings. Either of these two tasks could have been accomplished in a few short hours and it would have worked on all 1,500 recipes.

XSLT is a standard for converting XML to something else. The something else is growing rapidly.  Most frequently, the something else is XML in a different data structure. This article opened with a problem whose solution was to convert one XML file (with bad code) to another XML file (with good code). Other common formats created by XSLT include HTML and plain text. One of the most popular formats our company creates with XSLT is MS Word documents. Microsoft supports XML as a format for most or all of its Office 2003 applications. 

In this series, I also will introduce XSLT as a declarative language. I will describe the transformation process and explain some of the basic XSLT programming elements. The article will also discuss XSLT expressions, match patterns, recursion, templates, default templates, XSLT processors, scripting, and some of the limitations of XSLT. Finally, I'll point you to a number of resources and applications to help you learn more about XSLT and to get up the XSLT learning curve.

Putting It All Together
Learning a new language is not a trivial undertaking. There needs to be a big pay-off if you're going to spend the time to learn new data structures and languages. Rarely has a new language made your life better. This one will.

The final article will provide real world examples of what can be accomplished with XML and XSLT. I'll make sure to point out obstacles that commonly arise and how to over come these. I'll provide XML samples from real automation systems and accomplish tasks that have practical use in the everyday life of an automation engineer.

I hope that once we've finished this series you'll be well armed and ready apply these concepts to your everyday tasks.

PART 2
PART 3
Online Resourceswww.w3c.orgwww.xml.comwww.xml.orgwww.topxml.com
msdn.microsoft.com/xml
  About the Author

John T. Sever is president and founder of Cascade Controls Inc. Sever has more than 20 years of experience as a process and automation engineer and can be reached at 708/802-6000 or at [email protected].