XSLT 2.0 Web Development: Elements of a Web Site. Pt. 2 | 2

XSLT 2.0 Web Development: Elements of a Web Site. Pt. 2.

3.5.3.3. Multicomponent abbreviations

An address abbreviation may contain more than one component. This is often necessary to link to scripts (as opposed to static pages) that require a number of parameters in the request URI. Some of these parameters (e.g., the partner’s ID or formatting options) are static and can therefore be filled in by the stylesheet, but the key information pointers (e.g., the date and the number of the article within that date) must be present in the source of the linking page. Here’s an example of a link with a multicomponent abbreviated address:

As <foonews 
       date="02-12-2003"   
       num="6490">reported</foonews> by FooBarNews...

which could be expanded into the HTML link:

As <a 
href="http://foonews.com/news?date=02-12-2003&num=6490">reported</a>
by FooBarNews...

3.5.3.4. Internal links

One highly recommended abbreviation scheme that makes sense for almost any site is using page identifiers, defined in the master document, instead of pathnames11 for internal links. This will make your site’s structure much more flexible because you will be able to rename a page or move it around without changing all the other pages that link to it.12

Linking a foobar. For example, suppose you have a page on your site describing a product called Foobar Plus. You don’t want to spell out the complete pathname each time you link to that page, as it may be quite long (e.g., /products/personal/foobar_plus). Much more convenient would be using that page’s unique (within your site) and easy-to-remember identifier. Since you don’t, in all probability, have another Foobar Plus on your web site, it is natural to use an abbreviated name of the product as the identifier:

Check out our new <int link="fb+">Foobar Plus</int>!

The correspondence between web pages and their identifiers is to be set in the master document (3.9.1.2). Now it doesn’t matter if your Foobar Plus page is moved, say, from /products/personal/foobar_plus to /products/corporate/foobarplus. All you need to do is change the reference in the master document and retransform all site pages.

Aliases. To make life even easier for site maintainers, you can allow them to use any of a number of aliases referring to the same page. For example, the Foobar Plus page might just as well be linked to as fb+, foobar+, or foobar-plus. All you need to do is register all such aliases in the master document (see Example 3.2).

Linking translations. In multilingual sites, a special kind of link that must be present on every page is the link(s) to the other language version(s) of the same page. The absolute minimum of information needed to construct such a link is, obviously, the identifier of the language we are linking to. Thus, if we write on the Foobar Plus page

<lang link="de">This page in German</lang>

then the stylesheet will use the current page’s pathname to construct the proper HTML link — for example,

<a href="/products/personal/foobar_plus.de.html">This 
page in German</a>

or

<a href="/products/personal/foobar_plus.html?lang=de">This
page in German</a>

or any other variant, depending on your web site setup. Once again, the correspondence between languages and link URIs is deduced from the master document’s data.

3.6. Images and objects

The majority of static images, Java applets, and Flash animations on web pages are not independent objects. Most often, they are components of higher-level content constructs. An image may be a visual accompanying a section heading, a background of a table or the entire page, or a navigation button that is part of a larger navigation system.

In all these cases, your source XML will not contain any image references at all: It is the stylesheet’s responsibility to know what images to use with what content structures, where to take these images, and how to format them. Much less frequently, usually within text flow, you might need to display an image for its own sake — such as a photo, a technical illustration, or a map. It’s only these standalone objects that you’ll have to specify explicitly in the semantic XML source of a page.

This section covers both static images and various embedded objects such as Java applets, ActiveX controls, and Flash animations. All of these are similar from the viewpoint of XML source markup; below we talk mostly about images, but you should keep in mind that the same applies to most non-HTML external objects used on web pages.

Element type names. The name of the element type for including standalone images in your documents may be either generic (e.g., image) or specific (e.g., map or portrait). If you’re only planning to use a few well-defined types of images in a few well-defined situations, you can use narrow and descriptive names for each type. Otherwise (or if you do not yet have any specific plans for the use of images at all), a generic image element would be just fine.

Images as attributes. An image object may be quite complex, with additional components, such as a photo caption or credit, stored in attributes or child elements. However, quite often all you need to specify is a source location or an identifier for an image that is an attribute of some other object rather than a standalone object in its own right. For the image types that can be used this way, you can use an attribute of the same name as the standalone image’s element type. For example, if your sections may feature a photo next to the section’s heading, it is more convenient to write

<section image="location">
<head>Section heading</head>
...
</section>

than to write

<section>
<image src="location"/>
<head>Section heading</head>
...
</section>

even though your stylesheet may be programmed to create identical formatting for these two inputs.

3.6.1. Abbreviating location

Just as a link’s main attribute is the destination address, an image element must, before all, specify the location of the image resource. And, just as we used abbreviated addresses in links, it is natural to use mnemonic identifiers instead of complete image locations. For example, by writing

<image src="nymap"/>

instead of

<image src="img/maps/nymap.png"/>

you make your XML source more readable, easier to edit manually, and less prone to errors.

In the simplest case, an abbreviated image reference can be made from its filename by removing the path and extension (which is supposed to remain constant for all images). In more complex cases, an abbreviation might be composed of several parts expressed as attributes, such as a date or a classifier. Finally, your master document could simply store a list of all image locations associated with arbitrary identifiers and possibly aliases (compare 3.9.1); in this case, all image references in your source will be completely independent of the corresponding locations or other image properties.

Abbreviating aggressively. Along with stripping directory and extension, filename-based abbreviations can be made even more convenient by programming the stylesheet to perform case folding (converting everything to lower- or uppercase) and to remove all whitespace and punctuation. With these provisions, to reference img/maps/nymap.png in the above example, we could use any of nymap, ny map, N.Y. Map, and so on.

The goal of using abbreviations is to have your image references named intuitively and consistently and to provide just enough information in XML for the stylesheet to be able to reconstruct the complete pathname or URI.

3.6.2. Formatting hints

Standalone images may be particularly difficult to separate into independent aspects of content and formatting. The idea of specifying an image identifier and possibly its role in the XML source and then letting the stylesheet figure out all the formatting parameters is attractive, but the reality may be not so neat. Sometimes, you’ll have no choice but to add ugly formatting clues to the XML source to get the correct rendition.

An example is a layout where several images are placed on a page, interspersed with text, and aligned alternately against the left or right margin. It is natural to have the stylesheet do the alternating alignment so that only the image identifiers need to be supplied in the source. However, sometimes you may want to force a particular image to a particular margin in the middle of a page. Adding align="right" to your XML source is hardly semantic but may be unavoidable if, for example, a left-aligned image visually conflicts with a nearby left-aligned heading.

Think ahead. It is much easier to prevent a disease than to cure it. Thus, it is preferable to design your page layout in such a way that it can be created strictly automatically based on nothing but the semantic XML source. Avoid situations where only manual interaction can produce acceptable formatting.

For example, if you plan to use alternating alignment of images, you could either use centered headings (which will not conflict with either image alignment) or mandate that any image be at least one paragraph away from the nearest heading (this restriction is easy to enforce automatically using Schematron).

Created: March 27, 2003
Revised: May 24, 2004

URL: http://webreference.com/programming/xsltweb2/1