XML: A Manager's Guide

XML for Managers, Not for Dummies
by Alan Zeichick  

Every year has its favored buzzword technology, and we've all watched the software development field embrace (and sometimes discard) the special of the day. Sometimes those are concepts like object-oriented programming, component development, use cases, expert systems, unified modeling language or computer-aided software engineering. Less frequently they're specific languages, such as C++, Modula-2, Eiffel, Pascal or Java.

The Extensible Markup Language, or XML, can be thought of as bridging the conceptual and linguistic camps. Yes, it's a specific language, but it's not a programming language; it's a data description language. As such, the details of the language itself are deceptively irrelevant. It's the fact that the language exists at all, as a standard for the spontaneous interchange of arbitrary data, that makes XML supremely important. But that dual personality also can make XML difficult to understand. Isn't it just a different form of HTML? Isn't it just a watered-down version of the bloated SGML, the Standard Generalized Markup Language?

The short answer, of course, is "yes and no." The longer answer is "go read a book"-in this case, the aptly named "XML: A Manager's Guide," written by Kevin Dick.

You may recall David Taylor's excellent "Object Technology: A Manager's Guide," recently revised into a second edition. Taylor's book provided an overview of object-oriented development, which was sometimes a bit too simplistic for my taste, but it's still the best non-code-dripping book I've seen on that subject. Dick's XML book follows the same breezy formula, although it goes into more real-world depth than its decade-old predecessor. 

BEGIN IN THE BEGINNING
Dick begins in an appropriate place: discussing the data-delivery and data-exchange problems that enterprises and developers currently face. As he appropriately says, "For years, enterprises have searched for a technology that would help them synthesize data from different databases into different packages, depending on the needs of the particular user." That technology? If you said XMLwell, you'd be half right. The real answer is metadata, which is data about data. XML is a language for defining and encapsulating metadata, along with the data itself.

Want some examples? The number 2125553212 is just a number, but with metadata we learn it's a certain company's fax number. The number 16.125 could be the per-piece price of 80-ohm 200-volt resistors, the IPO price of a new Internet start-up, or the change in share price or the size that a typeface should be displayed on a Web page. From casual context, humans can infer the metadata, and understand what the data means. Computers can't do so. Hence, the need for a standard for defining metadata for software to understand: XML.

The second chapter in "XML: A Manager's Guide" discusses the basics of XML-what it looks like, and so on. Frankly, without a clear benefit, readers may get bogged down in an avalanche of Document Type Definitions, tags, elements and attributes. I suggest you jump instead to chapters 6 and 7, which introduce sample business XML applications for internal enterprise use and for conducting electronic business, respectively. This is the part of Dick's book that provides the "aha!" of understanding, and which will couple XML to your business-focused thinking gears. Many of the details will seem hazy-but you'll see how everything ties together.

JUMP BACK TO THE MIDDLE
Once you've gone through the examples, then jump back to chapters 2 and 3, to pick up the details of basic XML technology, as well as several key related standards that round out the XML spec, such as XML Style Sheets, or XSL, which define the presentation of XML data in an HTML browser; Namespaces, which allow the scope of metadata to be restricted to only relevant business domains; and XLink, the XML Linking Language, which provides hypertext features to XML metadata.

That's only the foundation. Without tools and processes, standards aren't of much use to enterprise developers. Chapter 4 provides a brief overview of the generic types of XML tools on the market, such as parsers or indexing tools. The tools it discusses are very low level-there's no discussion of the pros and cons of native XML databases or of the use of XML application servers as middleware in n-tier development, for example. Ahh, well, that's why we have second editions-and considering the pace of XML's evolution, I hope one is forthcoming within a year or two.

Chapter 5, which delves into the process of using XML in an enterprise context, is unfortunately light on specifics. It's true, as Dick says, that XML applications introduce change into an organization. Dick breaks XML applications into three categories-those for exchanging information between people, between people and applications, and primarily between applications-but, in my opinion, he doesn't sufficiently tie those into the real world or provide guidance for integrating XML into the development cycle.

Despite the weakness in those two chapters, "XML: A Manager's Guide" remains the most readable and accessible book I've found for a busy reader who just needs to "get it" quickly. Strongly recommended.