OLink Semantics in the DocBook DSSSL Stylesheets

Norman Walsh

10 Sep 1998

OLink allows you to construct cross-document links in SGML. This document describes the OLink semantics supported by the DocBook stylesheets.

Understanding OLink

The semantics of OLink are effected by both the OLink tag and the ModeSpec tag.


OLink is a wrapper around the text which forms the head of the link. It has four relevant attributes:


This ENTITY attribute points to the document which is or contains the link target.


Contains the ID of the target in the document specified by TargetDocEnt. LocalInfo is the equivalent of LinkEnd on the other linking elements.


Points to a ModeSpec element which further modifies the semantics of the link.


Identifies the link type. The DocBook stylesheets include special processing for Type=href.

If the link type is “href”, then the HREF attribute from the summary document is used directly, without redirection through a CGI script.


An OLink element can refer to a ModeSpec element to further modify the semantics of the link. Two aspects of the ModeSpec element are relevant:


If the content of OLink is empty, it is possible to use XRefLabel to control the format of generated text.

ModeSpec Content

If the content of the ModeSpec element is not empty, it is used by the HTML stylesheet in the contruction of the HTML link “href”.

OLinking in HTML

Constructing cross-document links with entities in the authoring system is all well and good, but how does it work on the web? The heart of the matter is mapping from the SGML/XML entity in the TargetDocEnt to the base URL on the web, and there are two options: early binding and late binding.

Early Binding

To use early binding, you must know the mapping from entities to URLs in advance. The base URL is supplied in the content of the ModeSpec element and that is what the processor uses to construct the HTML “href”. For example, given the document in Example 1, the stylesheet would generate something like this for the link:

<A CLASS="OLINK" HREF="http://nwalsh.com/otherdocs/myotherdoc.htm#idval">This
is an OLink</a>

Note that the LocalInfo is used as the fragment identifier.

Example 1. An Early Binding Sample Document

<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook V3.1//EN" [
<!ENTITY otherdoc PUBLIC "-//Norman Walsh//DOCUMENT My Other Document V1.0//EN">
<modespec id=otherms>http://nwalsh.com/otherdocs/myotherdoc.htm</modespec>
<title>Test Document</title>
<olink targetdocent=otherdoc linkmode="otherms" localinfo="idval">This is
an OLink</olink>.

Late Binding

Late binding delays the resolution of entity to URL mapping until the link is followed. It does this by requiring that a web server process resolve the link. “Out of the box,” the DocBook stylesheets assume that a cgi-bin script on the server called /cgi-bin/olink is responsible for the resolution.

Given the document in Example 2, late binding would produce a link something like this:

<A CLASS="OLINK" HREF="/cgi-bin/olink?pubid=-//Norman%20Walsh
This is an OLink</a>

(without the line break in the middle of the public identifier, of course).

Again, note that the LocalInfo is used as the fragment identifier.

Example 2. A Sample Document

<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook V3.1//EN" [
<!ENTITY otherdoc PUBLIC "-//Norman Walsh//DOCUMENT My Other Document V1.0//EN">
<title>Test Document</title>
<olink targetdocent=otherdoc localinfo="idval">This is an OLink</olink>.

If a public identifier is used to declare the entity, then it is passed to the link resolution script; otherwise the system identifier is passed.

OLink Generated Text

Even when links span across documents, it's useful to have the stylesheet generate appropriate cross-reference text. This greatly reduces the “fragility” of the links at the expense of some complexity in the OLink processing system.

If you supply content in an OLink, that content is always used and generated text processing does not apply.

The format of generated text is controlled by the XRefLabel attribute on the ModeSpec pointed to by the OLink. The text of the XRefLabel attribute is used for the generated text, with the following substitutions:


Is replaced by the “name” of the link target. This is generally the “human readable” name of the target element. For example, if the target is a Figure, %g would be “Figure”; if the target is a Sect3, %g would be “Section”.


Is replaced by the label (number) of the link target.


Is replaced by the title of the link target.

Suppose, for example, that the link target is the second section in the first chapter of a book and that it has the title “My Test Title”. If the XRefLabel attribute contains the text “see %g %n, %t”, then the generated content would be “see Section 1.3, My Test Title”.

Really Simple OLinks

If the author provides content in the OLink element, that's the content that is used and no extra processing is required. The sections that follow each deal with variations in the level of processing required for generated text in OLinks.

Simple OLinks

Simple OLinks avoid some of the gory machinery required to handle general OLinks at the expense of most semantic variation.

The simple semantics come into play when an OLink has the following form:

<olink targetdocent="entity"></olink>

In particular, note that there is no LinkMode. The generated text in this case is derived entirely from the public and system identifiers by the (olink-resource-title) function. By default, this is simply the title of the document derived from the description field in the public identifier. The first and last “words” of the public identifier description field are trimmed off, leaving what is presumably just the document title. For example, given “-//Norman Walsh//DOCUMENT My Document Title V1.0//EN”, the derived title would be “My Document Title”.

General OLinks

The generated text for general OLinks comes from the XRefLabel attribute on the relevant ModeSpec. The hard part is locating the appropriate replacement text: the name, label, and title of the element pointed to by the combination of the TargetDocEnt and LocalInfo.

One way to do this would be to load the TargetDocEnt, find the element with the ID mentioned in LocalInfo and extract the data directly. I chose something else because I see two significant problems with this approach:

  1. Loading and parsing potentially large documents potentially many times appears to have the potential for significant performance problems.

  2. It would not be possible to form OLink references to documents written in DTDs other than DocBook.

Instead of loading the actual target document, the stylesheets load a summary of that document's content. For DocBook documents, this summary can be generated by another DSSSL stylesheet, olink.dsl, supplied with the DocBook Stylesheet distribution. The first few lines of the summary for this document is shown in looks like this:Example 3.

Example 3. OLink Summary Document

<!DOCTYPE div PUBLIC "-//Norman Walsh//DTD DocBook OLink Summary V1.0//EN">
<div type="article" name="Article">
  <ttl>OLink Semantics in the DocBook DSSSL Stylesheets</ttl>
  <div type="sect1" name="Section" id="OLINK-UDERSTANDING" label="1">
    <ttl>Understanding OLink</ttl>
    <div type="sect2" name="Section" label="1.1">

The basic organization of the summary document is a nested series of divs and objs with titles (ttls). Attributes on these elements provide the IDs, labels, and names of the elements. The GI of the element is also provided. (If you find objects that you think are missing from the summary, please let me know).

The stylesheets locate this document by resolving the system identifier of the target document and replacing the SGML or XML extension with %olink-outline-ext% (.olink, by default).

Intra-document OLinks

If the TargetDocEnt attribute is missing, it seems reasonable to assume that the link refers to the current document. This actually offers a feature, you can customize the generated cross reference text for a particular reference.

When the OLink is an intra-document link, it is possible to use additional %-substitutions in the cross reference template. See (auto-xref) in dbcommon.dsl for more details.


The examples that follow are all links into the document shown in Figure 1.

Figure 1. Example Target Document

<article id="a1">
<?html-filename olinktarget.html>
<title>OLink Test Document</title>
<para>This document demonstrates cross-document linking with OLink. Format
this document with the <filename>olink.dsl</filename> stylesheet.</para>
<sect1 id="a1s1">
<title>A1 Section One</title>
<sect1 id="a1s2" xreflabel="Article Section Two">
<title>A1 <emphasis>Section</emphasis> Two</title>
<sect2 id="a1s1s1">
<title>A1 S1 Subsection One<superscript>1</superscript></title>
<sect2 id="a1s1s2">
<title>A1 S1 Subsection Two<subscript>2</subscript></title>
<sect1 id="a1s3">
<title>A1 Section Three</title>

The ModeSpecs in this document are shown in Figure 2.

Figure 2. Example Target Document

<modespec id=ms1 xreflabel="Name: '%g', Label: '%n', Title: '%t'"></modespec>
<modespec id=ms2 xreflabel="%g %n, %t"></modespec>

Example 4. An OLink with Content

Source: <olink targetdocent=olinktarget>some text</olink>

Result: some text

Example 5. A Simple OLink

Source: <olink targetdocent=olinktarget></olink>

Result: OLink Test Document

Example 6. An OLink to a Document

Source: <olink targetdocent=olinktarget linkmode=ms1></olink>

Result: Name: 'Article', Label: '', Title: 'OLink Test Document'

Example 7. An OLink to a Section

Source: <olink targetdocent=olinktarget linkmode=ms2 localinfo=a1s2></olink>

Result: Section 2, Article Section Two

Example 8. An Intra-Document OLink

Source: <olink linkmode=ms1 localinfo="olink-understanding"></olink>

Result: Name: 'Section', Label: '', Title: 'Understanding OLink'

Example 9. An XRef

Source: <xref linkend="olink-understanding">

Result: the Section called Understanding OLink