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

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

3.5.3. Abbreviating addresses

When creating a link, we usually want to specify a certain piece of content that the link will point to. What a URL allows us to specify, however, most often is a ﬁle that can be moved, renamed, or deleted even if the content we are interested in is still out there somewhere. Moreover, a URL includes a lot of technical information (protocol, ﬁle extension) that is not relevant for our purpose of establishing a content-level link.

All this invites the idea of using abbreviated addresses that would hide the underlying technical complexity of URLs and provide an abstraction layer protecting our semantic XML from URL changes. For each address, we will create an identiﬁer to be used in the XML source; at transformation time, the stylesheet will resolve this identiﬁer into the actual URL to be put into the corresponding HTML link element.

Example: RFC links. Suppose you often need to link to enumerated documents such as RFCs.¹⁰ Such links could use a special value of the link classiﬁer attribute and/or an element type of their own. However, to make them even more convenient, it is natural to use only the RFC number as an abbreviation for the complete URI:

...as per <rfc num="1489"/>.

Or, the same could be spelled out in a generic fashion:

...as per <link linktype="rfc" link="1489"/>.

This latter variant uses generic linking attributes that can be applied to different elements to make links out of the corresponding objects, whereas the num attribute is only recognized in an rfc element.

The XSLT stylesheet will have to recognize this type of link, possibly apply some special formatting to it, and most importantly resolve (unabbreviate) the abbreviated address. In this example, unabbreviation would supply the complete URL of the referenced document for the HTML link:

...as per 
<a href="ftp://ftp.rfc-editor.org/in-notes/rfc1489.txt">RFC 1489</a>.

You could also allow an rfc element to enclose character content:

...which was <rfc num="1489">defined</rfc> in 1993.

which would give the following in HTML:

...which was 
<a href="ftp://ftp.rfc-editor.org/in-notes/rfc1489.txt">defined</a> 
in 1993.

Mnemonic addressing.Abbreviated addresses in your source XML must be unique only within your site, as opposed to URLs that are globally unique. This means you can make them easier to remember and more meaningful (to you) than are URLs. The abbreviated addresses are also completely devoid of irrelevant technical details and can be arbitrarily long (i.e., detailed and readable) or arbitrarily short (i.e., quick to type and quick to read).

3.5.3.1. Multiple abbreviation schemes

You can use as many independent abbreviation schemes as necessary. Each more or less complete and logical group of addresses can be served by its own abbreviation algorithm (and the corresponding resolver in the stylesheet). For example, links to an online dictionary or search engine might be abbreviated to just the word you want to look up; links to W3C standards can be represented by their unique identiﬁers as used by the W3C site (e.g., xslt20 for XSLT 2.0, which unabbreviates into https://www.w3.org/TR/xslt20/). Any address domain whose URLs can be “losslessly compressed” into a shorter or easier-to-remember form is ripe for abbreviation.

With multiple abbreviation schemes, the stylesheet must be able to know which one to use for each link. This is where link types (3.5.2) are useful, distinguished by a classiﬁer attribute value (<link linktype="rfc" ...>) or the element type (<rfc ...>) used for each link. It is natural to deﬁne abbreviation schemes on a per-link-type basis, or even to deﬁne link types based on the abbreviation schemes they are using.

Along with resolving the address, your stylesheet can perform other processing tasks, such as retrieving the title of the referenced RFC to be displayed in the link’s ﬂoating tooltip. A Schematron schema for your source deﬁnition, in addition to performing link syntax validation, can also check for broken links (5.1.3.3). Another important advantage is that you can easily change all your RFC links from one RFC repository to another simply by editing the stylesheet.

3.5.3.2. Unabbreviation algorithms

To expand the abbreviated addresses, your stylesheet may use any sources of information, such as local or remote database queries or even web search. It’s easiest, however, to create simple algorithmic abbreviations that map to the corresponding URLs through some calculations or string manipulations.

Thus, for external links, the most obvious and perhaps the only sensible abbreviation is dropping the protocol speciﬁcation (usually https://) from the URLs. Even this simple provision can make address input somewhat easier by allowing you to type www.kirsanov.com instead of https://www.kirsanov.com.

Note, however, that in this case the stylesheet must be able to recognize the protocol part of an address and only add https:// if it is missing. Addresses that already contain a protocol speciﬁcation (be it https://, https://, or ftp://) must not be modiﬁed in any way.

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

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

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