Increasing Your Conversion Rate

Chances are you have seen that unusual trilogy of letters meandering around on bookshelves, technology newsletters, IT manager's desks and even splashed on the beloved Microsoft web site. If you listen to the voices in the fray, its the next best thing to sliced bread. Come to think of it, what WAS the best thing before sliced bread?

XML, or eXtensible Markup Language, may seem very new to you. There is a reason for that. It is! It really didn't even become official until 1999 when its spec was approved by the World Wide Web Consortium (W3C). Like other markup languages, it is a method for describing information so that every computer, and most humans, can understand it. It has much in common with HTML (Hypertext Markup Language), and in fact historically was spawned by a common parent, SGML way back in the 1970s.

Like all markup languages, XML was designed to manipulate information chunks independently from their presentation. Encoded instructions tell applications exactly what to do with these chunks much the same way as your word processor has commands to format a paragraph or bold the selected text. What has everyone so excited, is the extensibility, that is, its flexibility to easily adapt to the nature of the application for specialized situations.

The tech world has a bit of a mixed bag about XML right now. Businesses seem to be looking to XML to solve the problem of sharing information in disparate formats with applications across a wide range of platforms. Pure linguistic engineers look at XML as a "meta-language" or language to build languages. Still other entreprenuers are looking into the power of XML to enable new enterprise applications that can span as large as the world, because they are housed "in the net" and not on someone's workstation. A closer examination of these views, will prove that they are all correct. That is what makes XML such an exciting new technology.

In order to begin to understand the power of XML and its related technologies (of which there are many), we must first understand its power, structure and this elusive concept of extensibility. In order to do that, let's look at an example of HTML and see its structure and implied content:

Looking at this example, those of you that are familiar with HTML, know that this seems to be data that is in a table. But what does the data mean? Well, it has to do with someone named Tom Johnson, obviously, but what does Tom do? And what do these numbers mean? The 90346 could be his gross earnings last year as part of a payroll record, his first quarter sales numbers as part of a sales history report, or his zip code where he lives, for all we know. The last two things look like phone numbers but what phone numbers? Home? Office? Fax? Cell? Yes, if we had put in the TH headers we might could glean more, but they are not there are they?

Now let's look at the same example in an XML context:

See the difference? The tags in HTML (those things between the brackets) are fixed according to their specification. Each has specific uses and formatting characteristics. In XML, however, the structure is extensible meaning that the tags used are defined for the specific use involved for that application. XML allows the user to define these literally at will, and then render the information in a wide variety of formats using various XML compatible technologies such as a traditional cascading sheet (CSS) or through stylesheet translation (XSLT).

Such a structure is highly advantageous to us. If you think of how we process data in the real world, we do it in the context of our thought and use. A long time ago, in a land not to far away, we designed our computers to strip content from the actual data. We were forced to develop a contextual map (normally known as a schema), then create specific relationships between the map elements (i.e. relations), then strip the actual data out and stor it to be synchronous with the map. When we wanted to look at that data again, we had to write programs to match that data with the schema, then present it. In essence, we stored the data and context separately

XML gives us another shot at that same problem, but in an age when new speeds of technologies enable us to rapidly transform and translate information. Instead of stripping out the context separately, it is stored with the data according to rules set forth by its specific application (a document type definition or DTD). What is absolutely stunning about this, is that the actual XML data can reside in context, where extraction is a very simple stylesheet (instead of programs), and translating this data to new formats is as simple as applying a new DTD for its use.

Imagine the capabilities of this technology! Today, businesses receive hundreds of thousands of transactions per data from partners and customers. In order to make things work, programs are constantly written to translate the date from one incoming transaction format to another so a resident application can pick it up and process it. Now, what if the resident application had the capability of reading these XML tages and knowing hot to process the data. Dozens of programs disappear, transactions are processed faster, and overhead and maintenance of applications become simpler. Businesses are just now beginning to see these benefits, but its only the tip of the iceberg.

Taking this one step further, into the area of development and maintenance, imagine an application that can morph with change. A typical database application has hundred if not thousands of tables. In turn, each of those tables have multiple relations to other tables, creating a near impossible situation to maintain without major toolsets, and a bevvy of DBAs. Now, imagine you have a large data set that revolves around that schema and you need to change something...say, add a field or two. Even worse, if that field is important and you have to make it a key field! The task to retool the affected tables, relations, and application software is gargantuan. But with XML, which stores the data in context, it is simply a matter of placing the data out there and manipulating it in the stylesheets. What takes months or years to change in a traditional database, now only takes a matter of a few hours or days. Quite impressive yes?

Obviously there are trade offs. There is no free lunch, and new technology proves that everyday. In a future post, we will explore those trade offs of an XML strategy in application development and deployment, and how integrative techonologies such as XSLT can pave the way to new horizons in information management.