Creating an HTML/WML Portal

May 15, 2000

Didier Martin

At home, Internet portals help us navigate the information ocean. At work, an enterprise portal is our virtual view of the organization. Now that publishing a document is just at a click away, we need more than ever tools that help us reach the right information at the right time. These tools also act as filters on the overwhelming information flow.

A portal fulfils this role by providing features such as:

• Aggregating content
• Organizing content
• Searching through document collections

The best way to understand the internals of a portal is to create one. So, we'll move to the labs and build a portal prototype. But first, let's explore some underlying principles.

Layout Principles

Figure 1: Web browser view of portal	Figure 2: WAP phone view of portal

The two figures above illustrate two different views of the same portal. The left-hand view is what you get when you access the Yahoo portal with your browser. The second view is what you get when you access the same portal with a digital cellular phone equipped with a WML browser. Thus the same portal has in fact two "doors".

We got so used to the Yahoo type of portal layout that most of us have some trouble imagining other ways of presenting this kind of information. But other layouts can be envisioned, such as a start layout as found in "The Brain" (http://www.thebrain.com), or more simply a dual-paned layout like Windows Explorer. These two alternative layouts are particularly efficient for presenting hierarchical structures.

Yahoo-like portals present the information as a collection of small windows. These small windows have all kinds of monikers such as "widgets", "portlets", "gadgets", "gizmos" and so forth. Let's reduce this plethora of names to a single one, and call these small windows simply "portal windows".

On HTML browsers, these portal windows are laid out in rows and tend to be stacked one on top of the other:

Figure 3: Typical HTML layout of a portal

Digital cellular phones have a limited display screen. Most of them support only 5 lines of text and no images. The most recent ones, like the toy I recently bought, have 11 lines of text or 120 x 160 pixels to display images.

These phones can browse the web with a WML browser. WML is an XML-based language: more information about it and the protocol used to transport WML documents can be found at the WAP forum. In contrast to HTML, where one document is downloaded and displayed at a time, a WML document contains more than one page, each page constituting a "card". This feature partly limits the ping-pong game between the server and the cellular phone, and thus compensates for the limited bandwidth available.

Figure 4: Mapping of portal content to a WML document

To display the same information in these two kinds of browsers, web publishers can simply produce two sets of documents, one for the HTML browsers and another for the WML browsers. This solution has the obvious drawback that it is expensive.

A better solution is to separate the views from the model, and to publish a single document. This can then be rendered differently with different style sheets for each browser. Thus, we create a single portal with two doors: a single model with two views.

The Model

A portal home page is composed of information units, aggregated from different service providers. A service could be located on the same machine, or located remotely. The first goal when creating a model for portals is to create a basic portal atomic entity to model these information units. For the sake of this article, let's call such an entity a netfolder; a kind of network folder.

A network folder or netfolder can contain almost any kind of content as long as it is encoded with the XML format. The netfolder is not dependent on a particular rendering language, nor does it convey any rendering information. A netfolder can be displayed or rendered in different ways, and with different rendering languages. For instance, it can be displayed as a WML card, or as a small portal window laid out inside an HTML document.

As we mentioned previously, a portal page is often used to aggregate content. To do so, we'll use the <xinclude:include> element (see http://www.w3.org/TR/xinclude) to pull XML document fragments from external sources. The XML inclusion mechanism is still a work in progress, but we'll use it as an excellent candidate method for content aggregation.

Each <xinclude:include> element get its content replaced by the XML document fragment referred by the href attribute. This substitution operation is performed by an XSLT style sheet. Hence, we use the XSLT processor as an XInclude interpreter. Figure 5 illustrates how this might be done utilizing content from Moreover.com.

Figure 5: Aggregating content with XInclude

This example XML portal document source shows how aggregated elements might work with other content items described using XLink.

Now that we have the basic elements for our portal home page model, we'll see how this single document gets transformed into HTML for browsers, and into WML for digital cellular phones. However, because the WML example needs more explanation than just a paragraph or two, we'll cover it fully in the next Style Matters column.

Rendering for HTML Browsers

If have examined the example XML document, you will have noticed that it includes no special instructions for rendering. So, from this model we need to create an HTML view.

HTML browsers allow you the creation of a rich visual environment for your information. An XSLT style sheet can add value to the basic XML document information units with new objects like images, animations, vector drawings and so forth. Before reading further, take a look at the XSLT style sheet: XSLT style sheet to transform the portal document into HTML

The XSLT style sheet transforms all the <netfolder> elements into visual objects that we referred to earlier as portal windows (see Figure 3). It also imports and includes external contents by interpreting the <xinclude:include> element. This is done in XSLT with an XPath extension introduced by the XSLT 1.0 Recommendation, the document() function.

The document() function takes a URI as its parameter, and returns a node list. The node list is then processed by the templates, matching the elements included in the returned XML document fragment. Of course, our XInclude interpreter is quite rudimentary, but it illustrates the potential. For instance, if you apply the XSLT style sheet on our portal document, then you'll get the latest news feed about e-commerce from Moreover, an XML service provider.

Rendering for WML browsers

If rendering the XML document in an HTML browser meant adding additional information elements, in the case of WML browsers it means removing information elements. Five lines of text and a slow connection is a real challenge, and the best attitude is to use Occam's razor and keep only the strict minimum. This means that in the case of a news feed, we display only the headlines and a very short abstract.

We'll explore WML rendering fully in the next Style Matters column. Until then, I am always available to listen to your XML lab stories! Just drop me an e-mail.