Using XML as a Static Content Solution...

For web sites that have a large amount of static content pages, the content is usually consisting of a raw HTML page that is usually edited directly, rather than the content coming from a database, XML file, or other source...

By: Brian Mains Date: November 7, 2005 Download the code.

For web sites that have a large amount of static content pages, the content is usually consisting of a raw HTML page that is usually edited directly, rather than the content coming from a database, XML file, or other source. This is a daunting task because HTML doesn’t support include files, which means that the HTML layout for the site does have to exist in each and every page. As an alternative, variants of HTML do support include files, but what if the design of the article content needs to be changed? What about changes that management decides to make within an organization? For example, what if an organization wants to change bolding of text from the "b" element to the "strong" element, which would be used throughout the content?

One possible solution is the use of XML. How would this work? Take an article for example, which would utilize a known and limited set of HTML elements. Each of these HTML elements would have an associated XML element. For example, the strong element would be represented by the XML element <Bold>. This element provides a layer of abstraction, meaning that the user doesn’t have to understand exactly how HTML works; rather, they need to know a limited set of supported elements within the XML file. An alternative approach could be a custom application that handles this. Some of the abstractions created for the attached example are:

HTML Element Associated XML Element

The transformation from <Bold> to <strong> occurs in the XSL stylesheet. The XSL stylesheet takes the data in the XML and renders it as HTML tags. At first, it appears that there's no added benefit to this; rather, more typing is involved (<Underline> instead of <u>). But from an organizational standpoint, complexity in HTML elements can be more easily approached. For example, what if an organization uses the following HTML to represent a title and text description that is indented?

With this complexity, XML could make this solution simpler. Instead of all of the HTML code above, all that is needed is this: <Indent Title="Title">Text</Indent>. This is much simpler to implement, and if this complex structure changes in the future, it is easily modified. In addition, an XML element could be as simple or as complex as desired, and tends to be cleaner than HTML can be. It could use all attributes, or use child elements; the complexity is up to the designer.

As a more realistic example, articles use quotations from documented sources. The way quotations are documented in each article will vary. In some sources, they may be placed outside of the article to the left or the right of the article for emphasis of a specific point, as a separate paragraph, or as italicized text within the same paragraph. However an organization wants to represent this, all that is needed it a <Quotation> xml element.

Let’s look at the attached example. The article rendered from the XML source contains a resource element. This resource element has the following child elements: Information, Attachments, and Content. An empty XML structure would look like this:

The rest of the article below is technical and requires knowledge of XML and XSL stylesheets. The examples will show each of the above XML structures individually, then immediately will show the XSLT that renders it in the browser.

The first element, Information, contains the name, author, and creation date of the article. These details are rendered together at the top of the article in the underlying page; each can be omitted or could be rendered in different areas of the article.

The header at the top of each article will be the title of the article, the name of the author, and the date that the article was created. The header in this example uses the <h1> element, and requires a stylesheet with the stylesheet class of Title. This can be changed; it could use no styles, or propogate the style from an XML attribute.

Some articles contain attachments or files that are linked to in the article, which could be sample source code, executables, or zip files. The Attachments element surrounds one or more Attachment elements, which contains the name of the file, the URL (and optional external URL to reference from an outside web site) to the file, the size of the file (optional), and a description of the file (optional). The attachment element supports an Internal and NewWindow attribute, determining whether the attachment is an internal attachment, or whether the attachment should appear in a new window.

The Attachment element has many similarities with the Link element (appears later), with the exception that the child elements (<FileName>, <FileUrl>, etc.) are actually attributes for the Link element). It may seem that the Attachments element could reuse this Link element, but that is not the case. More on this later.

The attachments are rendered as hyperlinks, which are either internal or external references to the file, depending on an Internal Boolean flag. Each attachment exists in an HTML table; this table adds structure and organization to the layout of the attachments. There are certain properties for an attachment that are optional; if they are not provided, then nothing is rendered.

Content for articles is paragraph-based; a content is broken up into one or more paragraphs. Each paragraph has its own styles and settings; for example, it could be separated by a newline above and below it, or it could start with the first line indented. Links, text styles etc are embedded directly in the paragraph element. The following is an example of content:

Content rendering is simple in nature; the paragraph calls apply-templates to call the appropriate template. When the parser encounters a Bold element, it will call the Bold template; when it encounters the Quotation element, it calls the Quotation template, and so on. The parser handles this nicely in that it will render the child elements with the text as you have it formatted.

The appropriate templates for each element is shown below. The XML element (for example, Bold) renders the appropriate HTML (for example, strong). More complex elements require more processing (if statements, etc.), but overall, it is not very difficult to perform rendering of HTML even more easily through the use of this XML template. In addition, more options could add more complexity and functionality as desired, through the use of xsl:if and xsl:when statements.

This article has examined how the parts of the document are rendered, but we haven’t yet looked at the structure that organizes the article. This is where part of the power of this strategy comes into play; in the XML document, the <Resource> element is the header element. The XSL stylesheet has a template for this <Resource> element, which renders a table organizing each of the parts (Information, Attachments, and Content). This one element controls how the entire article is rendered. When changing the layout of an article in the future, such as when you are changing a web site look and feel, only the XSL stylesheet must change.

What is the difference between the Attachment element and Link element? Other than the fact that the properties are child elements for Attachment and attributes for Link, there is an importance for the separation of the two. First and foremost, Attachment contains additional properties that Link doesn’t. Secondly, attachments render differently than links do; they render a description and a file size in addition to the link. The idea was that overall, attachments would be different than Links, especially in an organization. However, the two elements could be merged into one if so desired.

The ASP.NET web application code that renders the link is very simple; it uses the XML control to render the content of the XML file to the web page. This approach utilizes the site layout instead of the ASP.NET, rather than embedding the HTML for the entire site layout in the XSL stylesheet. In addition, only one ASP.NET page could be used, where the DocumentSource is dynamically assigned to the XML control based on the querystring, session, or other source.

Determining Content

An assessment is needed to determine if this approach will work for an organization. If content generated is very simple in nature, this implementation will work; however, if static content regularly uses varying HTML elements (not a standardized set), or a wide array of elements, this approach may not be suitable. Content that is dynamically generated or may vary from page to page may not be suitable for this approach. The approach outlined here is more for content that doesn't change in its HTML usage.