Reducing Web Site and Application Maintenance using XML with ASP

Paul Spencer

XML in 60 Seconds

By now you will have a good idea of XML. I am therefore just highlighting those aspects that are relevant to this paper.

Ø        XML is a first cousin to HTML

Ø        XML allows us to define our own tags and attributes

Ø        We can make these tags and attributes mean what we want

Ø        We can display XML using CSS, XSL or Databinding

Ø        We can manipulate XML with the DOM

In particular, the combination of XML, XSL and the DOM give us the power to do whatever we want with XML code.

How XML can Ease Maintenance

There are several ways in which using XML can ease maintenance. Principal among these are:

Ø        When data is being sourced from various different places, enforcing an XML format then using an XSL stylesheet can ensure control over the display format.

Ø        When the same data is being used for several purposes, only one copy is required. For example, I keep a list of English counties as an XML file and use it for different purposes in different applications.

Ø        Maintaining the data for a site navigation frame in XML allows you to customize the frame for different browsers without duplicating data.

Ø        Maintaining data that is common across different web pages in XML, either using a DTD and entity references or embedding the information in an XSL stylesheet, avoids duplication of data and so makes site modification easier.

Paul Spencer: Paul is managing consultant for Boynings Consulting (www.boynings.co.uk), a leading UK internet consultancy specializing in the development of relationship management solutions and in helping companies understand and apply the latest available technologies. Paul is a strategy and technical consultant, project manager and trainer. He is the author of : XML Design and Implementation, published by Wrox Press.

Three Examples

The following examples illustrate these points. For the first two, I will explain how XML was used, then I will describe the third in more detail.

Consistent Display from Different Sources

Consider a simple travel application. In this scenario, a central server holds searchable information about various travel-related items, such as hotels, theatres and trains. This server has links through the Internet both to the systems of larger operators such as hotel chains and to regional servers that hold information about many items such as bed and breakfast establishments. These establishments update the data on the regional systems periodically.

How does this look from the user end? Initially, our two users are filling in a screen with search criteria. When they search for hotels in Seattle with a pool and beauty salon, they will see a list of properties that has been provided from the central database. They can then click on an item from the list. At this point, the central sever does not have further information to display. Instead, it requests information from either a remote host or a regional host that holds information for the Seattle area and displays this in a window.

Let’s stop at this point and think about the display. As the operator of the central system, we will want the display to contain the information we specify in a style that is consistent across all hotels. We might allow some customization, but our own branding requirements stop us relinquishing total control.

A few years back, the best we could do would be to specify an HTML format, and maybe provide a CSS stylesheet. This hardly does what we want as we can only change the style of individual elements, not add information or restructure the display.

Now try this with XML. We can hold an XSL stylesheet locally and use the information sent from the remote host as a simple source of data. For example, this will tell us the name of the hotel, rather than inform us that we have a piece of text to display in 18pt Arial, centered in its own block. Immediately, as the owners of the system, we remove a huge task of vetting data to ensure that our layout rules are being obeyed.

Different Displays from the Same Source

The corollary to the above is where we have a single data source and want to display the information in different ways. I mentioned this in passing above, but will give two examples here, both from travel.

Example 1

The first is a reservations system for packaged vacations. This system allows a company to manage its inventory of vacations, while making them available to travel agents using a technology called Viewdata. I don’t want to knock Viewdata as I was involved in its early development fifteen years ago, but let’s face it - a technology that provides a text-only display on a 40x24 screen using modems with a downlink speed of 1200bps and an uplink of 75bps is a bit past its sell-by date.

As well as selling the system, the manufacturer runs a hosted service for several of its customers. In this scenario, each tour operator has its own virtual system. With the limitations of Viewdata, the displays for each manufacturer were very similar, and the only branding used the limited block graphics available with Viewdata.

In the last few years, the system supplier has developed a web-based front-end for this system. With the extra flexibility this allows, tour operators now want customized and branded displays throughout the system. This is the current scenario:

1.      The manufacturer develops a set of generic web pages using ASP, HTML, ADO and Script to display the various pages

2.      These pages are tested

3.      The pages are then sent to the graphic designers to customize them for the customer

4.      The pages are re-tested and found not to work

5.      The pages are corrected

Of course, if the company is hosting systems for twelve customers, this happens twelve times. Then, when they update the system and have to change the database extraction code, they have to do this twelve times.

This is obviously a development and maintenance nightmare, so let’s see how XML helped them.

Ø        Instead of pulling data from their database into HTML, they now pull it into XML.

Ø        Because they have a consistent XML format across all tour operators, the graphics designers don’t touch the database code, but instead develop twelve sets of stylesheets.

Ø        Because the graphic designers have not touched the code, it still works.

Ø        When the application changes, the stylesheets can stay the same, or be changed to take advantage of new facilities.

To do this, all the company needed was to load IE5 onto its IIS4 server. Once IIS5 is released, even this won’t be necessary. Because all the XML processing is being carried out on the server, the system is compatible with any browser.

Example 2

My second example is the system I developed for my book “XML Design and Implementation”. In this application, a user can select criteria for a packaged vacation:

 

In this case, we have found vacations from two suppliers - Argo Holidays and Panorama Holidays. We can then look at the details for one of these vacations:

Because the data is all held in XML, this is rendered using an XSL stylesheet. Although XML can also be rendered using CSS, XSL has the benefit that we can change the order in which the data appears, and even add text and images if we want to.

This part of my paper is about displaying similar information in different ways, so let’s say that Panorama has paid a premium to have its own display layout. Because this is sitting in a window in my system, I want to maintain the overall look and feel, but allow some changes. How about this:

We have moved the pictures, some of the text and removed some information. If we looked further down the page, we would see that all pricing information, which is in a table on the Argo page, has been removed. How long did it take me to make these changes? Less than five minutes. And what if we had been extracting the data from a database directly into HTML? Rather longer to change, and we would have required a lot more testing. As with the previous example, if I wanted to make changes to the underlying system, this would also have been far more complex if rendering directly into HTML.

Using XML When Neither the Server nor Browser Supports It

My final example, and the one I will describe in detail, is based around my own web site. The site is divided into three types of page - applications designed to show XML operating client-side using IE5, static pages and a navigation frame. Naturally, I want the static pages and navigation frame to display in the most popular browsers, in particular with Explorer and Navigator from version 3 upwards. I also want to reduce the amount of work I have to do when I decide to change the layout of the site, which I do periodically. I will show in a moment how XML can achieve this.

Unfortunately, the site is hosted on a system that does not have ASP or XML support and I don’t want to go through the hassle and cost of moving it to another ISP. My solution was therefore to develop the site in XML and pre-process it through a couple of simple stylesheets using ASP to generate HTML files which I then upload onto my ISP’s server. Naturally, if your site supports ASP and XML, you could create the pages on the fly every time they are requested. However, you might like to consider the additional load on the server if you do this. This is the home page:

Let’s look at how I built this site, then we can look at the advantages over an HTML-based site.

The Static Display Pages

The first point to consider is that, apart from the navigation frame which I will describe in a moment, these are static display pages. The tags will therefore be mainly display-related and we already have a tag set that achieves this - HTML. Unlike every other XML-based project I have undertaken, my tags will therefore mainly describe display characteristics rather than the meaning of the data. This is not universally true - I have replaced the clumsy HTML <META> tags with some of my own. Of the display-orientated tags, I am supporting two types - specific HTML tags, such as <TABLE>, which I use in upper-case, and some of my own, such as <pagelogo>, which I use in lower case. Since some parts of my pages are best described in HTML, I have also introduced an html element. Anything within this element will be treated as HTML and copied directly to the output.

Here is my complete tag set:

data-orientated tags	HTML tags	Other display tags
description keywords robots created modified script cdata()	TABLE TR TD SELECT OPTION MAP AREA A	doc docinfo body pagelogo image para span list listitem button html

As you can see, many of the tags listed under “other display tags” are just pseudo HTML tags - this reflects the type of data I am encoding.

Now we have to create our display using XSL. We do this by creating templates that describe how each of the elements and their attributes is to be translated into HTML.

The XML descriptions of the pages are split into two parts - docinfo and body. Here is the template for docinfo:

<xsl:template match="docinfo">

  <HEAD>

    <xsl:apply-templates select="description" />

    <xsl:apply-templates select="keywords" />

    <xsl:comment>Created: <xsl:value-of select="/.//created/@day" /> <xsl:value-of_ select="/.//created/@month" /> <xsl:value-of select="/.//created/@year" /></xsl:comment>

    <xsl:comment>Last modified: <xsl:value-of select="/.//modified/@day" /> <xsl:value-of_ select="/.//modified/@month" /> <xsl:value-of select="/.//modified/@year" /></xsl:comment>

    <LINK rel="stylesheet" type="text/css" href="boynings.css" />

    <xsl:apply-templates select="robots" />

  </HEAD>

</xsl:template>

(Unfortunately it is a feature of XSL, especially if you want to avoid additional white space, that lines become very long. Lines that get broken when pasted into this document are shown with an underscore character at the end.)

As you can see, this template starts by applying the templates for description and keywords, then adds comments for the dates when the page was created and last modified. Following this, we have the link to an external CSS stylesheet, and then we apply the template for the robots element. That template inserts a META tag, with an attribute called content that contains the value of the content attribute of the robots element:

<xsl:template match="robots">

  <META>

    <xsl:attribute name="name">robots</xsl:attribute>

    <xsl:attribute name="content"><xsl:value-of select="@content" /></xsl:attribute>

  </META>

</xsl:template>

The description and keywords elements are treated similarly.

For the defined HTML elements, we have a template that just copies the tag, the attributes and any text directly to the output:

<xsl:template match="TABLE | TR | TD | SELECT | OPTION | MAP | AREA | A | BR">

  <xsl:copy><xsl:apply-templates select="@* | * | text()"/></xsl:copy>

</xsl:template>

I mentioned earlier that I also allowed blocks of HTML included within an html element. I did this partly because I was copying material from existing HTML pages, and partly because I found it easier sometimes not to have to think too much about whether I had included specific tags in my stylesheet. Of course, I could have done this for almost every HTML element, but chose not too as it means adding the <html></html> tag pair each time. This is the template that handles that case:

<xsl:template match="html">

  <xsl:apply-templates>

    <xsl:template match="* | @*| comment() | text()"><xsl:copy><xsl:apply-templates select="@* | * | comment() | text()" /></xsl:copy></xsl:template>

  </xsl:apply-templates>

</xsl:template>

This is similar to handling individual HTML elements, but in this case, the processing is recursive, so embedded elements will be processed.

I hope by now I have explained how to create the display-orientated templates. What about when we have script on a page? Here is some script within the XML description of a page:

<script>

<![CDATA[

function onLoad()

{

  var str,browser;

  if (navigator.appVersion.indexOf("MSIE 4") != -1)

    document.all("ie4").innerHTML = '<A href="salesie4/sales.htm" target="_top">Try the_ system</A>';

  if (navigator.appVersion.indexOf("MSIE 5") != -1)

    document.all("ie5").innerHTML = '<A href="salesie5/sales.htm" target="_top">Try the_ system</A>';

}]]>

</script>

The script itself has been placed within a CDATA section so that the parser does not try to process it. This is how we want the output to appear:

<SCRIPT>

//<!--

function onLoad()

{

  var str,browser;

  if (navigator.appVersion.indexOf("MSIE 4") != -1)

    document.all("ie4").innerHTML = '<A href="salesie4/sales.htm" target="_top">Try the_ system</A>';

  if (navigator.appVersion.indexOf("MSIE 5") != -1)

    document.all("ie5").innerHTML = '<A href="salesie5/sales.htm" target="_top">Try the_ system</A>';

}//-->

</SCRIPT>

And here are the two templates that achieve this, ensuring that the script is properly embedded within HTML comments:

<xsl:template match="script">

  <SCRIPT>

    <xsl:apply-templates select="@*"/>

    <xsl:apply-templates />

  </SCRIPT>

</xsl:template>

<xsl:template match="cdata()">

  //<xsl:comment><xsl:value-of />//</xsl:comment>

</xsl:template>

The Navigation Frame

You can see from the screen shot earlier that I have used a simple navigation frame that reflects the hierarchy of the pages through indentation. This is the XML file that described that frame:

<?xml version="1.0"?>

<?xml-stylesheet type="text/xsl" href="toc.xsl"?>

<toc>

  <entry href="main.htm" text="Home" />

  <entry href="relation.htm" text="Relationship Management" />

  <entry href="xml.htm" text="XML">

<entry href="book.htm">Book - XML Design and Implementation</entry>

    <entry href="x-eg.htm" text="Examples">

      <entry href="x-eg1.htm" text="Multiple Outputs from one XML source" />

      <entry href="x-eg2.htm" text="A Browser-based Sales System (IE4 &amp; IE5)" />

      <entry href="x-eg3.htm" text="XML for Data Collection (IE4 &amp; IE5)" />

    </entry>

    <entry href="x-tut-fr.htm" text="DOM Illustration" />

    <entry href="x-links.htm" text="XML Resources" />

<entry href="seminar.htm">XML Training</entry>

    <entry href="x-serv.htm" text="Boynings Consulting's XML Services" />

  </entry>

  <entry href="about.htm" text="About This Site" />

  <entry href="profile.htm" text="Consultant Profile" />

</toc>

Information about each page is contained within an entry element that uses attributes to identify the page URL and the text to display. Where a page has a hierarchy of sub-pages, these are contained as further elements within that element.

And here is the stylesheet we use to process it:

<?xml version="1.0"?>

<xsl:stylesheet

  xmlns:xsl="http://www.w3.org/TR/WD-xsl"

  xmlns="http://www.w3.org/TR/REC-html40"

  result-ns="">

<xsl:template match="/">

  <HTML>

    <HEAD>

      <LINK rel="stylesheet" type="text/css" href="boynings.css" />

      <META name="robots" content="noindex,nofollow" />

    </HEAD>

    <BODY>

      <DIV align="center"><IMG height="81" src="images/logo.gif" width="125" /></DIV><BR/><BR/>

      <xsl:apply-templates select="/toc" />

    </BODY>

  </HTML>

</xsl:template>

<xsl:template match="toc">

    <xsl:apply-templates/>

</xsl:template>

<xsl:template match="entry">

  <DIV>

<xsl:attribute name="Style">margin-left:1em; font-size:<xsl:eval>_

12-depth(this)</xsl:eval>pt</xsl:attribute>

    <A target="right">

      <xsl:attribute name="href">

        http://www.boynings.co.uk/<xsl:value-of select="./@href" />

      </xsl:attribute>

      <xsl:value-of select="./@text" />

    </A>

    <xsl:apply-templates/>

  </DIV>

</xsl:template>

</xsl:stylesheet>

The first template merely provides the HEAD element of the HTML document, including linking to a CSS stylesheet. The toc template, which matches the root element of the XML document, then causes further templates to be processed. The template that does all the work is the one for the entry elements.

This first creates an HTML DIV element. We then use the <xsl:attribute> element to create a style for this. This indents the margin a small amount and sets a font-size that will decrease with the depth of indentation. It is important to note that, since the DIV elements are nested, the indentation is cumulative. The remainder of the template is straightforward, adding an anchor (A)  element and the required text.

This template has produced a simple navigation frame that is compatible with both Explorer and Navigator from version 3 upwards. You can see how simple the stylesheet is, and how easy it would be to produce more complex designs, such as collapsing tables, compatible with different browsers. It is then simple to detect the browser in client-side script and load the appropriate page. Of course, all these pages are generated from a single XML file, so there is only one place to change the information when the site content changes.

Building the Pages

So far, we have all our static pages and the site navigation information described in XML, and we have XSL stylesheets to turn them into HTML. Let’s see how we go about this.

When I built the site we are looking at, I put all the XML-related files in a sub-directory called “source”. I then created two other files: a list of the pages and an ASP page called “make.asp”.

This is the list of pages:

<?xml version="1.0"?>

<files>

  <file>main</file>

  <file>about</file>

  <file>xml</file>

  <file>commerce</file>

  <file>x-eg</file>

  <file>x-eg1</file>

  <file>x-eg2</file>

  <file>x-eg3</file>

  <file>x-links</file>

  <file>relation</file>

  <file>seminar</file>

  <file>x-serv</file>

  <file>profile</file>

  <file>book</file>

  <file>toc</file>

</files>

And this is the file that does the processing;

<%@ LANGUAGE = JScript %>

<%

  // get the set of files to process

  domFiles = Server.CreateObject("Microsoft.XMLDOM");

  domFiles.async = false;

  domFiles.load(Server.MapPath("make.xml"));

  if (domFiles.parseError != 0)

    Response.Write(domFiles.url + ": " + domFiles.parseError.reason + "<BR />");

 

  root = domFiles.documentElement;

 

  // start the display table

  Response.Write("<TABLE>");

 

  // now transform each one and save it

  for (var i = 0 ; i < root.childNodes.length ; i++)

  {

    // get the XML file

    domSource = Server.CreateObject("Microsoft.XMLDOM");

    domSource.async = false;

    var file = root.childNodes.item(i).text;

    domSource.load(Server.MapPath(file + ".xml"));

    if (domSource.parseError != 0)

      Response.Write(domSource.url + ": " + domSource.parseError.reason);

   

    // if there is a stylesheet PI, get the stylesheet (otherwise use make.xsl)

    var style = "make.xsl";

    for (var j = 0 ; j < domSource.childNodes.length ; j++)

    {

      var current = domSource.childNodes.item(j);

      if (current.nodeType == 7 && current.nodeName == "xml-stylesheet")

      {

        var strPi = stripSpace(current.data);

        var start = current.data.indexOf("href") + 6;

        var end = current.data.indexOf(".xsl") + 4;

        style = current.data.substr(start,end-start);

      }

    }

   

    // load the stylesheet   

    domStyle = Server.CreateObject("Microsoft.XMLDOM");

    domStyle.async = false;

    domStyle.load(Server.MapPath(style));

    if (domStyle.parseError != 0)

      Response.Write(domStyle.parseError.reason);

   

    // process it

    result = domSource.transformNode(domStyle);

   

    // save the resulting HTML in the parent directory

    var objFSO = Server.CreateObject("Scripting.FileSystemObject");

    var location = Server.MapPath("..") + "\\" + file + ".htm";

    Response.Write("<TR><TD>" + location + "</TD><TD> stylesheet is: " + style + "</TD></TR>");

    var objNewFile = objFSO.CreateTextFile(location);

    objNewFile.Write(result.toString());

    objNewFile.Close();

  }

 

  // end the display table

  Response.Write("</TABLE>");

 

function stripSpace(strInput)

{

  return(strInput.replace(/[ \t\n]*/g,""));

}

%>

This file loads the list of files and processes each in turn. Each file contains a processing instruction to identify its stylesheet (although they are all the same apart from the navigation frame, I wanted to maintain this flexibility). The correct stylesheet is then loaded and the XML file transformed to HTML before being written back to disk in the parent directory.

Meanwhile, the results of the processing (and any errors) are written to the browser. When all goes well, we get this display:

Now I can load the HTML pages onto my ISP’s server.

And that is all there is to it. We have created a web site in XML that does not require XML support on either the client or the server. In fact, all the server has to do is serve the HTML pages.

The main advantages of this are:

Ø        the navigation frame is unbelievably easy to maintain as the site content changes.

Ø        only a single list of pages is required for the navigation frame, even when different versions are required for different browsers.

Ø        common text in pages can be included in a single stylesheet rather than on every page

Ø        if required, a DTD could be used to verify content and provide text substitutions

Ø        the site layout can be completely redesigned just by changing stylesheets

Summary

These examples show some of the maintenance benefits gained by using XML in the development of web sites and applications. In particular, we have seen how we can:

Ø        ease the control of display formats when data comes from different sources

Ø        make it easy to customize display formats for different customers or different browsers

Ø        use the same information in different places without having to maintain more than a single copy