XML in Web Development

I l @ ve RuBoard

Let's look at some of the implications of using XML and XSLT in Web site development, so we can see what advantages they offer to the team. What we mean is developing the site in such a way that every page is encoded as XML before it is transformed for display into HTML by an XSLT style sheet. This is a very important design decision that requires the development team to follow some strict rules.

The First Law of XML Web Development

The first and most fundamental rule is that no formatted HTML code should be generated anywhere other than in the XSLT style sheets. We call this the first law of XML Web development, and it means that static content stored on the file system should be encoded as XML rather than HTML. It also means that any programming code that retrieves data from databases or business objects for display on a Web page should always mark up that data using semantically meaningful XML tags rather than formatted HTML. The XML is concise and direct: As we said earlier, tags mark up content semantically with tag names that are similar or identical to names of objects, properties, tables, and columns used by the program.

Using the Schema Document

The content of various pages and sections of a site will have different XML structures. It is important to decide on the exact nature of those structures, which can be formalized by a schema document. A single Web site may use different schemas for different content sections of a page. Most sites will contain some generic copy for which a schema using familiar HTML-like paragraph and heading tags may be appropriate. An e-commerce site will have pages that contain product descriptions, requiring a schema with element and attribute names like "product," "description," "price," and " size ," and an order placement system that makes use of XML node names such as "shopping cart," "quantity," and "shipping address." One way of managing this is to specify the structure of each content type using separate subschemas and then creating a "master" schema that references these subschemas.

There are many efforts under way to standardize DTDs and schemas for specific industries and business domains, and it always makes sense to look for a standard schema or DTD that fits your needs before you write your own, even if your current requirements are only for internal use. Doing this could very well lay the groundwork for future interoperability of your system with others.

One important function of a schema is as a contractual agreement between the various producers and users of XML. This is true in much the same sense that an application programming interface (API) is often a contractual agreement between developers of classes and developers using those classes. For businesses exchanging purchase orders encoded in XML messages, this agreement ensures interoperability of the systems involved. For a small Web team consisting of programmers, content managers, and style sheet designers, this agreement ensures that the XSLT templates created by the designers will work properly with the content and the dynamic data.

Using the XSLT Style Sheet

Once the first law of XML development has been accepted as a development practice, responsibility for all of the "look-and-feel" formatting of the site rests in a single location, the XSLT style sheet. With it designers become free to work on the design of the site unfettered by programming concerns. They can specialize in XSLT and HTML and do not need to learn a plethora of APIs and general-purpose programming and scripting languages because their XSLT skills are portable from one environment to the next . At the same time programmers are relieved of the burden of responsibility to graphic designers.

Separating Content and Formatting

By encoding all content as XML, you completely separate content from formatting. This is in keeping with the classic n-tier software architectural principle of separating presentation from business logic and data access. In fact, this approach can be described simply as implementing the presentation tier in XSL and using XML as an interface between it and the business/application logic tier .

The fact is that there is nothing you can do in XML/XSLT that you can't do with programming code. What XSL adds is tremendous simplicity and elegance . In addition to the important advantage of separate responsibilities for programming and design, there are numerous other ways in which this separation of content from formatting benefits a Web development team.

Code Reuse

By marking up page content with a semantically meaningful XML structure, you open up new possibilities for code reuse. To illustrate this, let's look at a Web page that displays international currencies and their current exchange rates relative to some base currency. The page is built dynamically with JSP by querying an object that has access to a periodically updated currency feed. Rather than having the JSP return an HTML page with the currencies laid out in a table, we code the JSP to output an XML file that looks like this:

 <exchange_rates base="USD">       <currency symbol="EUR">            <name>Euro</name>            <rate>0.8532</rate>       </currency>       <currency symbol="CAD">            <name>Canadian Dollar</name>            <rate>0.6492</rate>       </currency>       <currency symbol="USD">            <name>United States Dollar</name>            <rate>1.0000</rate>       </currency>       ...more currencies here </ exchange_rates> 

You can do many different things with this. You can create an XSLT style sheet to display a list of exchange rates as an HTML table. You can then create a new set of XSLT templates to produce a DHTML currency calculator. Or you can create a whole new set of style sheets to format the rate table and calculator using WebML for display in a Wireless Application Protocol (WAP) browser. All of this can be done without ever touching the original JSP.

You can also make the currency table available as a Web service. Remote customer applications can retrieve the raw XML from the server and parse the data for internal use. With a little bit of work, you can even add some functionality to support SOAP-formatted requests and responses, outputting the same XML structure inside a SOAP wrapper.

Redesigning a Site

A related advantage of separating content from formatting reveals itself when it is time for a graphic design overhaul of the site. All of the design code resides in a set of XSLT files located conveniently in one place, which greatly simplifies the redesign process. Compare this to a traditional Web architecture, where HTML formatting code is scattered around and embedded in a jumble of script code and HTML files.

Asynchronous Development

An unexpected effect of design/content separation of is the ability to support asynchronous development. That is, programmers and style sheet designers can work on their areas without being affected by each other's progress. Asynchronicity can be easily accomplished by the use of dummy XML files, with which you can create output templates for dynamic pages before the dynamic functionality is completed.

Let's take a basic shopping cart application, in which a shopping cart and its contents can be represented by an XML file.

 <page name="shopping_cart_view"> Cocoon  <title>Your Shopping Cart</title>         <content>             <shopping_cart>                 <item code="53942">                     <description>"radical" wool knit sweater                           </description>                     <qantity>1</quantity>                     <size>XL</size>                     <color>green</color>                     <unit_price>.99</unit_price>                 </item>                 <item code="36671">                     <description>Calbert Climb Slim Fit Jeans                           </description>                     <quantity>1</quantity>                     <size>                         <waist>32</waist>                         <leg>28</leg>                     </size>                     <color>black</color>                     <unit_price>.99</unit_price>                 </item>             </shopping_cart>         </content> </page> 

When the site is first created, a sample shopping cart can be created and saved as a static XML file, allowing the XSLT style sheet designer to design the "View Shopping Cart" page. In the meantime the programmers develop a shopping cart application with an object that outputs an XML representation of the cart using the XML tag structure. As a first step they create a JavaServer Page (JSP) or Active Server Page (ASP) that simply writes out the same dummy XML as in the static page and uses it to replace the static XML file. When the shopping cart functionality is done, they can modify the JSP or ASP page so that it gets the data from the shopping cart object and dynamically generates the XML. Immediately the dynamic XML is integrated with the Web site, with the same layout and formatting as for the dummy XML page. The XSLT style sheet doesn't know the difference between the static and dynamic XML.

The asynchronous development process is summarized in this table.

Development Style	Programmer	Style Sheet Designer
Paired	Agree on XML structure for particular content section Create static dummy XML file Create simple XSLT templates to display dummy XML and add to master style sheet
Asynchronous	Draft schema document Add unit test to validate new XML against DTD Replace static dummy XML file with code module that statically outputs same dummy XML Interface with business objects, replace dummy XML with dynamic data	Rework initial templates to reformat page layout Add graphical elements Develop DHTML interface enhancements

Dummy XML

The use of dummy XML as a placeholder for XML content is good practice. In fact, it is often useful to insert it in static content pages before the actual copy is available. We have developed a practice of starting off all of our pages with a few lines of Latin. Our dummy XML files are very simple, as shown here:

 <page name="about_us">       <title>About Us</title>       <content>         <p>Lorem ipsum dolor sit amet, consetetur sadipscing elitr,  sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum.</p>          <p>Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr,  sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.  At vero eos et accusam et justo duo dolores et ea rebum.</p>         <p>Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr,  sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.         </p>        </content> </page> 

Greeking

Inserting meaningless dummy text as a placeholder for content is called "Greeking" and is very common in page layout. The "Lorem ipsum" phrase we use appears often in this context and has been used in the publishing industry for this purpose for many years .

At first dummy text may seem unnecessary. Why not simply wait until the real copy is available? In fact, we consider "Greeking" an important part of our process. What we do is to start developing a site by creating a dummy XML file for every page in the initial site map. At the same time, we start off with a simple and generic XSLT style sheet that transforms the dummy pages into HTML using a very generic and bland design.

Menus

The style sheet also generates menus that allow you to click on links that take you from one page to the next. It contains a number of navigation templates, which use the XML site map to build these menus. We haven't mentioned the XML site map until now, but it is an important ingredient in an XML site architecture and will be discussed in more detail soon. The site map ties all of the separate content files together.

Continuous Integration

Initially creating a collection of dummy XML files and generic style sheets makes it easy to create a skeletal prototype of the Web site during the first iteration. This prototype contains placeholders for each of the pages initially identified in the first version of the site map and tells how to navigate between them. Basically it provides a starting point for all future development. Meaningful content, dynamic functionality, sophisticated navigation, and stylized design are added by changing the various style sheets and XML pages.

In this way the architecture supports a sort of continuous integration process. What we mean by this is that at all times a complete working site can be browsed in entirety without errors. At first the site will contain meaningless information and have a bland design, but as work is done on it, the style sheets and dynamic or static content pages are updated so that the site evolves from skeletal to fully fleshed.

Continuous integration keeps customers involved in and informed about the progress of a project, in keeping with XP practices. Once an initial site map has been drafted, the site skeleton can be created rapidly with minimal effort. It can then be deployed on the preview Web server by the end of the first iteration and presented to the customer. The skeleton may not look impressive, but it can still be considered an actual deliverable . Moreover, as development continues, it gradually evolves into a dynamic, attractive site whose progress can be shown to the customer at the end of each iteration. Finally, because of the aforementioned asynchronicity between design, content development, and programming, progress is continual and demonstrable.

Having an initial functionally navigable skeleton during the first iteration starts things off on the right foot , providing the structural framework for the rest of the project. As programmers and content developers continuously replace dummy XML code with new XML content and dynamic data, they immediately see this new material integrated into the site, with proper design and formatting in accordance with the current style sheet. This makes it natural for them to adhere to the first law of XML development and eliminates any temptation to revert to HTML encoding.

I l @ ve RuBoard