Web Techniques: Coming to Terms with Extensible Markup

Coming to Terms with Extensible Markup

By Michael Floyd

My Uncle Clayton is, by any standard, an old-world programmer. His pony tail, now more white than gray, hangs dangerously close to his belt line. His favorite T-shirt, a faded, double-X, Grateful Dead vintage, is now too short to tuck in over his belly. His claim to fame is that he programmed on the world's first PC, the Altair, by setting switches to represent bit values. His favorite programming language is still, of course, Assembly Language.

Uncle Clayton and I have a great rapport, but when it comes to XML, he makes no bones. "XML?" he asks bluntly, "you might as well call it seXML." He's referring to all of the hype, so I quip back: "Well, if your name is Joe Homepage, you probably don't care much about XML." Indeed, if you're part of a Web-design shop that, for a nominal fee, will set up a "Web presence" for the small business owner, you probably don't need to care. XML benefits applications of a larger scale and purpose.

Unrelenting, Uncle Clayton jabs back. "My boy, XML is just a fad. It's time you get over it." Of course, Uncle Clayton knows that XML lets you separate data from presentation and business logic. That leads to all kinds of benefits, not the least of which is device independence. By using XML to mark up my data, I can publish it once on my Web site, and transform it to any other language I choose. I can output HTML that's customized for display in Netscape Navigator 4, or I can generate Cascading Style Sheets (CSS) that can display the same data differently in Internet Explorer 5. In fact, my data can be displayed on a wireless device, or even rendered in WebTV.

I'm revealing my excitement by the descriptions I'm using. At this point, Uncle Clayton appears to show some interest. I continue by explaining that in a B2B environment you can use XML to send data from an IBM mainframe to a Unix or Windows 2000 server without all of the proprietary formatting that goes with it. Companies are interested because XML lets them communicate with business partners without relying on proprietary formats or retooling in-house systems. In other words, it allows heterogeneous systems that were never designed to communicate to exchange data seamlessly in a network-friendly manner.

Uncle Clayton tugs a bit on his beard, and with a shrug he turns and walks away. I can't really blame him. It still sounds like hype, and marketing words bounce off Uncle Clayton faster than Barry Manilow lyrics ricochet off his Jerry Garcia T-shirt. All Uncle Clayton hears is that XML is the promised land, the silver bullet. And so the question for him remains: "Why should I care about XML?" Maybe the best way to answer this is to closely examine a high-end Web site.

Case in Point

If you work on sites that deal with large amounts of data and need to target that data for different devices, you should consider using XML. For example, your site might offer a shopping tool for comparing products—CNet offers such a service in its CNet Shopper section. This service lets you comparison-shop for items on the Web. Items are available through different retailers, and the service includes descriptions, pricing information, and links to purchase each one. CNet also offers a service called a "price drop alert" that notifies you if and when the price of a particular item falls. You can have your price drop alert sent to your email address, a phone, or your pager.

Developers responsible for creating such a system might begin by putting together a script that scans various shopping databases, pulling appropriate product information, and assembling a comparative list as usual. Normally, the results of this scan are compiled on an HTML page that's sent back to the user's browser. However, rather than shipping the list out in standard HTML, imagine the possibilities if the data were an XML stream.

Your first option is to send the XML stream directly to any XML-aware application. The application doesn't have to be a browser—it could be a Wireless Application Protocol (WAP) Server, which then broadcasts that data to your customer's PDA. The same stream could also be sent directly to an XML-aware client, like a browser or email package. Sending data to such clients offloads processing strain from the server by letting the client lay out and present the resulting data. And as you've been told before, XML lets you transform the same data into any format you choose. Sure, it could be HTML in a conventional browser or an email client. It could also be a transformation from some internal XML format to Wireless Markup Language (WML) for processing by a cell phone or pager device. The point is that XML lets you take the same data and publish it anywhere you need it.

Products

One reason XML has seemed like a lot of hype with little reality is that there have been few products that actually make XML development, integration, and deployment easy. Fortunately, a number of solid packages are finding their way to market. The thinkXML2000 package, from thinkXML, is a good example. It lets Web developers rapidly create sites using a forms-based approach to development. This is an interesting product because it lets the Web developer reap the benefits of XML without having to be an XML expert. Watch for this trend to grow as more products use XML under the hood, thus providing the benefits of XML while hiding the intricacies of Document Object Model (DOM) programming, XSL transformations, schemas, and the like. For a list of current XML products, see " Online Resources."

The thinkXML2000 package is similar in concept to the Rocket XML framework that I've developed in past columns. But thinkXML, which runs on Windows 2000 Server, is light years ahead in terms of its implementation. That's not surprising because Rocket is a more a proof of concept, while thinkXML is an industrial-strength tool complete with all of the bells and whistles, documentation, and technical support you'd expect in a commercial product.

There are three major components to thinkXML: A development environment, called the Management Console (see Figure 1); a runtime server; and a transaction server. The Management Console and the runtime server work together. The former is a sort of integrated development environment (IDE) that lets you quickly produce XML form applications that work with any HTML 3.0+ browser on any device, without plug-ins. You can associate event-based scripts with the form, or attach external ones. Within the form, you can create the typical form-based controls such as text edit boxes, drop down lists, and so on. All of the controls are data-bound, meaning they can contain data in a database. The thinkXML package actually uses Microsoft's ActiveX Data Objects (ADO) to retrieve relational data through an ODBC connection.

You can also attach field validation, assign regular expressions, and create custom attributes. Once the form has been created, you can link each form schema to a theme. The form schema is bound as an XML data island to a table cell within an HTML document. It's then transformed by XSLT. ThinkXML uses Cascading Style Sheet (CSS) classes to format the HTML form. Another cool feature lets you import existing HTML and PDF forms from any Web site and convert them to XML. The business logic is automatically generated for you. Once you've created your form, you can publish it with the publishing wizard.

The runtime engine accepts browser requests, performs browser detection, and serves the forms you've created in the console. For example, if the browser making the request is Internet Explorer 5 or later, the runtime server can send XML directly and let the client process the form. The runtime server also supports caching and free threading, and performs load balancing to maximize scalability and performance. According to the company, "the runtime engine is capable of processing millions of transactions per day using digital signatures, and integrating with any modern or legacy back-end system." Finally, the runtime server can submit XML to any transaction processing system, including the thinkXML Transaction Server.

The Transaction Server is an optional product that handles back-end processing using a message-queue architecture. The transaction server sends XML transactions to enterprise application integration (EAI) and B2B platforms, including BizTalk and WebMethods. Enterprise resource planners (ERPs) and other workflow systems can also accept thinkXML data as XML messages using the Queue Abstraction Layer without requiring any middleware or custom coding. In fact, thinkXML can send XML through any message queue, or directly to a file system or native XML database, such as Software AG's Tamino.

XML Catalogs

MarketAgility Express from SoftQuad Software is another product that uses XML under the hood, but hides XML from the user. At $995, the recently released this product is an affordable catalog builder aimed at the emerging Internet procurement market. If you're familiar with Ariba, then you know that it already offers a platform that brings suppliers and buyers together. MarketAgility Express, designed to work with the Ariba B2B Commerce Platform, allows small and medium-sized suppliers to create their own customized product catalogs for these Internet procurement systems.

On the surface, MarketAgility Express is a Windows-desktop application complete with a GUI, wizards, and online help. The data-import wizards let you import from Microsoft Access or Excel, then create catalogs that are output in Ariba's Catalog Interchange Format (CIF) or cXML format. Under the hood of MarketAgility, however, is an embedded version of Softquad's XMetaL, which provides enhanced data validation. Validation lets individual product entries be checked and ensures that catalogs work seamlessly with different Internet procurement systems. Of course, XMetaL's well-known editing capabilities let users search for, modify, and save entries that are stored underneath as XML elements—again, without realizing they're actually editing XML data.

Looking Forward

XML is so important to enterprise-level organizations that companies like Adobe, Microsoft, Sun, and IBM have set aside their differences and collaborated to further develop the language with ancillary standards, including the Document Object Model (DOM), eXtensible Style Sheet language (XSL), the XSL Transformation language (XSLT), and the XML Path language (XPath). Now, XML is being used for everything from application and database development to middleware messaging. It's finally gaining momentum because the tools are arriving to support it. More importantly, because the language is shaping up to be the standard means for representing data, it's affecting computing systems across the board. Anywhere there's data, there's a potential to use XML.

Despite what my bit-twiddling uncle believes, XML will become an important skill to add to your resume. Consider that a recent survey of Developers.net, an online recruitment site, turned up over 20,000 postings listing XML as a preferred job skill. More importantly, tool vendors are embedding XML capability into their product lines. While you may not have to know everything about XML, you will need to become familiar enough with it to use the next generation of products and build the next generation of applications.

Michael teaches "Serving XML with Active Server Pages" and is the author of Building Web Sites with XML from Prentice Hall. He's the architect of the Rocket XML framework and Editor at Large at Web Techniques. You can contact him at mfloyd@lifestylesSantaCruz.com.