[This local archive copy is from the official and canonical URL, http://www.oreilly.com/people/staff/crism/xsl/linkreq.html; please refer to the canonical source document if possible.]

Hypertext Link Support Requirements for XSL

Christopher R. Maden

Senior Tools Specialist

O'Reilly & Associates, Inc.

90 Sherman Street
Cambridge, MA USA 02140

World-Wide Web Consortium XSL Working Group

Revision 0.111 May 1998Initial draft.
Revision 0.212 May 1998Filled out transclusion section.

Abstract: The XLink and XPointer specifications provide a level of hypertext functionality that has not previously been available for widespread use. To succeed as a stylesheet language under these new conditions, XSL must address certain styling problems introduced by rich hypertext, including stylistic treatment of link ends and styling of transcluded text.


The XLink[1] and XPointer[2] specifications provide complex hypertext capabilities for XML documents. Two features with direct impact on the styling of XML documents are the creation of links whose link ends are in a different location from the link specification and the inclusion of one document, or a part thereof, in another as an apparent part of another document.

[1] <URL:http://www.w3.org/TR/1998/WD-xlink-19980303.html>

[2] <URL:http://www.w3.org/TR/1998/WD-xptr-19980303.html>

As part of its mission to offer functionality beyond that available in CSS, XSL should treat hypertext artifacts as first-class objects. Any link end known to the processor should be addressable, and the stylesheet should have access to any available information about that link end. XSL must also address the stylistic and intellectual property issues raised by the possibility of transclusion, as outlined in Problems with Dynamically Assembled Document Portions, and Some Solutions.[3]

[3] DeRose and Maden, in Proceedings of SGML/XML '97; also at <URL:http://www.oreilly.com/people/staff/crism/transclu.html>.

Link End Formatting

In XLink, simple (or inline) links are represented by an element at their origin. Since XSL provides means for addressing elements in the document already, this adds no new requirements. However, extended links can create link ends that are at a different point in a document, or even in an altogether different document, from the point where the link is specified. A link end is not bound by element boundaries; it can cross them and it can start or end in the middle of an element. XSL must provide a means of treating link ends as units of information to be formatted, and must specify behavior when the same information participates in multiple links.

XLink also specifies a means of providing information about a link and its link ends: a role, a title, and behavioral qualities. XSL needs to specify the means of access to this information when formatting a link end; for example, to provide different formatting for link ends with different roles. XLink allows the author to rename key attributes to avoid name conflicts; XSL should provide unambiguous access to the semantics of the link, regardless of the names used to specify them.

The requirements for link end formatting, then, are:


The other very interesting feature of XLink is the ability to include another document, or a portion of another document, dynamically at a point in the present document. This was dubbed "transclusion" by hypertext pioneer Ted Nelson. Steve DeRose and I analyzed the stylistic problems presented by transclusion in the paper referenced earlier.[3] The conclusion that we reached is that transclusion problems can be decomposed into three classes of problems: proper display, addressing of transcluded data, and modification of the transcluded data.

In the area of display problems, we found that stylesheet control is necessary for proper handling of transclusion. First of all, transclusion may be desired in the absence of an explicit XLink instruction; for example, fetching the title of a referenced chapter is a form of transclusion. But alternately, the designer may legitimately wish to include the entire chapter within her document; the stylesheet must be able to make that distinction.

The stylesheet must also be able to exercise control over inheritance. For example, a document whose default stylesheet specifies twelve-point Caslon may transclude a poem whose default stylesheet specifies eleven-point Futura. The designer wishes to preserve the Caslon context; and further, to establish a ten-point and wider-margin context for the translucded content; but to permit further formatting from the poem's stylesheet, such as italics, to take place unhindered. The stylesheet needs to enable these specifications, and in general, to specify what other formatting is to be accepted from the transcluded text's stylesheet. Increased margins in the poetry should be honored, but not necessarily with the same values as given. These specifications will be complex, but must be feasible.

There's also a question of altered interpretation of the data itself. A reference to an item in a list may wish to use the item's original context, perhaps to generate the text "item 5: weld the sprocket to the widget." But a series of items may be included in a list, and their numbering should be done in the context in which they appear instead.

A final question is that of modification. Our paper suggested that modification specifications might be contained within the element specifying the transclusion itself, but it's open to question whether acting on such specifications is the role of the linking engine or of the stylesheet. The stylesheet may wish to specify such modifications itself, and its processor is more likely to have implemented an expression language, making it a more likely candidate.

The transclusion requirements, then, are: