Why you should care about XML
By Tim Landgrave
Published in TechRepublic's Windows Enterprise Strategies
I'm beginning to see a disturbing trend among the corporations I work with on a daily basis. Many of them are so focused on Y2K issues, that they're falling dangerously behind in the race to maintain their current customers.
What race, you ask? Talk to the traditional "bricks and mortar" competitors of upstarts like Amazon.com or E-trade. They're having their lunch eaten by new, online competitors that were able to erode their customer base with relatively modest capital investments. As you know, Venture Capital firms have been more than happy to fund almost any firm–if it just puts the word "Internet" in its prospectus.
You have to ask yourself, what's a bigger challenge to a firm that has extensive retail outlets or traditional sales channels: ensuring Y2K compliance, or fending off a well-funded competitor that doesn't have to contend with huge infrastructure costs? Most of these displaced companies would no longer argue that a Y2K failure couldn't possibly cause as much long term damage to their business.
So how do you stay ahead of your existing and future competitors? You begin implementing systems that use nascent, yet inevitable technologies while using proven distributed application development techniques. One of these nascent, yet inevitable technologies is XML (Extensible Markup Language).
At the October Microsoft Professional Developers conference in Denver, Microsoft threw in a few last minute seminars on XML. These were held in smaller rooms under the assumption that few people have yet recognized the strategic importance of the technology.
Microsoft was wrong. Every XML session was standing room only (with hundreds turned away) and required the conference planners to scramble to find additional time slots to repeat the sessions. Why all the interest in XML from these developers?
Look, I've been in this business long enough to get past the hype associated with new technologies. If your development staff isn't already on top of this, then your company is already way behind.
HTML = Presentation, XML = Data
These formulas are gross oversimplifications, but help to explain XML's importance. In other words, what HTML does for presentation, XML does for data. HTML made it easy for anyone to publish information that's accessible anywhere in the world, through the use of a browser that implements certain published standards. XML allows applications to intelligently share data across the same backbone that carries HTML. The beauty of XML is that it can be extended easily.
HTML primitives define the layout of a page that the browser interprets when rendering the display. XML primitives define the layout of anything that an associated Document Type Definition (or DTD) can define.
In fact, HTML and XML are both descendents of the Standard Generalized Markup Language (SGML) designed in the 70's to allow passing of formatted documents between different systems. HTML has a fixed DTD that's built into every browser. XML on the other hand can pass a DTD used to interpret the corresponding XML. But XML parsers can also make intelligent decisions about XML files that are passed to them.
A simple example
If you use a browser to make an HTML request to an Web server asking for all the books written by a particular author, what you'll receive is a series of HTML commands and embedded text that displays a table containing the book information. If you want to do any additional processing on the book information, then you have to make an additional request to the server. If you make the same request to an XML-enabled "Data Server," you'll get something quite different. Instead of a formatted page, you'll get a file that looks something like this:
<BOOKS>
<TITLE>The Firm</TITLE>
<PUBDATE>1991</PUBDATE>
<TITLE>The Partner</TITLE>
<PUBDATE>1997</PUBDATE>
</BOOKS>
What you have is a set of data and the column definitions passed back to you. Since you asked for John Grisham novels, you don't need to have the Author information returned. But now, even without the associated DTD that defines TITLE as a text string and PUBDATE as a standard date type, the XML parser in your browser can be programmed using DHTML to display the books in any format. More importantly, by writing some simple client-side Jscript code, you can have your browser display only books that were published after 1988.
So how do I really use XML?
Giving web servers the ability to pass around data sets instead of just passing formatting commands opens up all kinds of interesting possibilities. It allows disparate systems to pass around data in standard formats that other systems can interpret.
For example, some Network Management Vendors are beginning to use XML to report real time system management information instead of their proprietary protocols. This allows real interoperability between competing Network Management software products, and lets web-based consoles interpret and act on the information.
XML will also become the dominant format for information passed between Electronic Commerce and Electronic Data Interchange (EDI) providers. Using XML eliminates the need or desire for creating bridging systems between incompatible providers. If your E-Commerce or EDI vendor doesn't have an XML effort underway, dump them quickly! (Or prepare to pay a company like mine to add the functionality later.)
You should also consider using XML as a transport for moving data between legacy and next generation systems. I'm working with a customer who has a legacy system running on a Honeywell mainframe. They can't afford to rewrite all of the applications, but they also understand the need for moving to a distributed environment. We're working with them to develop a limited XML parser for the mainframe. This will allow a middle-tier web server to pass data and start processes on the mainframe and then return the results to the middle tier in XML. The data can then be repackaged and distributed to browser-based applications.
By using the middle tier to communicate with the established mainframe processes, we can preserve the processing rules that have been in effect for years, but also make it easier in the long term to replace the back end with a new system. As we replace specific back end processes, we can leave the desktops alone. The middle tier servers are dynamically producing all of their data (XML) and presentation (HTML) code.
You should also look at retooling your Databases and document management and retrieval systems, so that they can provide their results in XML format. When vendors upgrade these systems to return XML sets, you 'll be able to request data from an SQL database regardless of its underlying required network transport. We'll have real "Data Servers" like we have Web servers today.
By storing documents using XML and complex DTD's, document management systems will be able to support more intelligent searches and return more complex documents. For example, a document management system storing research reports could return a formatted document with just summaries on a specific topic or detailed research reports from the same document store.
How is Microsoft Supporting XML?
XML is a case that supports my contention (which I know not everyone shares) that much of the bashing Microsoft gets for not supporting Internet standards is a case of picking on the big guy because it's fashionable.
Microsoft is represented on every major committee involved in the specification of XML standards. Microsoft has also released XML parsers for general use and implemented XML in IE 4.0 and in the downloadable beta of IE 5.0. I've listed Microsoft's XML web material in the References box on this page.
Recommendations for getting a jump-start on XML
So how do you make sure you're not left behind? Here are three quick recommendations.
Build an XML Library: You should be building a library of XML articles, books and training materials for your software developers and web masters. You may even want to appoint an XML SME (Subject Matter Expert) in your organization to stay on top of the latest developments)
Require XML Support in your system applications: Challenge the vendor of every new system application you purchase to explain their XML strategy. These applications include Network Management, Document Management, Database Management, Browsers and Development tools.
Build data publishing applications in XML: The best way to learn the technology is to start using it.
Don't let your concern for Y2K issues cause you to be unprepared for the future distributed applications environment. Start using next generation technology now or you could become the next corner book store to post the "Going out of Business" sign.
Tim Landgrave, Editorial Director of the Windows NT Technology Letter, is the Principal of Kizan Corporation, a Microsoft Certified Solution Provider. You can reach him at 502-992-8078 or at timl@ncctech.com.
Source of Content:
.gif "flaglogo")