XML Linking and Style

1.1 Design Principles

The task force used the following principles to develop the model described in this note:

1. The model must support applications of linking and styling for the purpose of presentation to a human audience.

   There are countless XML linking applications that are not related to style at all (robots, indexing applications, etc.). At best, the conceptual framework described in this note may aid in developing interoperable, standard applications of this sort. At the very least, nothing in this note should inhibit the development of XML linking applications that are not related to style.

2. The model must not compromise accessibility.

3. This model must apply equally well to XSL and CSS.

4. The consequences of linking to or from non-XML resources is outside the scope of this note.

1.2 Requirements Framework

In considering this design, we felt the following requirements had to be met by any proposed solution:

1. The overall treatment of the ending resource is controlled by the xlink:show attribute.

2. The overall treatment of link traversal is controlled by the xlink:actuate attribute.

3. It must be possible to style both starting and ending resources.

4. It must be possible to process inbound, outbound, and third party arcs.

5. It must be possible to process starting resources regardless of "well-balancedness": whole documents, one or more whole nodes, an arbitrary range, including partial nodes, and non-contiguous selections of all of the above.

6. It must be possible to process ending resources regardless of "well-balancedness".

7. It must be possible to control the context in which ending resources are displayed. While whole documents are the standard context for web browsers, it is easy to imagine situations where it would be desirable to show a portion of the document that contains the target, or even just the target itself.

8. We must consider the consequences of encountering different sequences and nestings of starting resources with various combinations of behavior settings.

2.1 XML Link Identification

XLink linking elements may or may not participate in the link they identify. Consider the following example:

<doc>
<p><name xlink:type='simple'
      xlink:href='students/patjones62.xml'>Pat Jones</name>
is taking <course xlink:type='simple'
      xlink:href='#CS101'>CS-101</course>.</p>
<courselist>
<course id='CS101'>Computer Science 101</course>
<course id='CS201'>Computer Science 201</course>
</courselist>
</doc>

In this example, the two green (and underlined) elements are starting resources. The blue (and italic) element is an ending resource. There is no explicit markup to identify ending resources, but an XLink-aware application can identify them because they are pointed to by URI references.

Linking relationships can be less obvious. Consider the case where an extended link is used:

<doc>
<extendedlink xlink:type='extended'>
  <loc xlink:type='locator' xlink:label='cs101'
      xlink:href='#xpointer(//course[@id='CS101'])'></loc>
  <loc xlink:type='locator' xlink:label='cs201'
      xlink:href='#xpointer(//course[@id='CS201'])'></loc>
  <loc xlink:type='locator' xlink:label='cs101desc'
      xlink:href='courses/cs101.xml'></loc>
  <loc xlink:type='locator' xlink:label='cs201desc'
      xlink:href='courses/cs201.xml'></loc>
  <arc xlink:type='arc' xlink:from='cs101' xlink:to='cs101desc'></arc>
  <arc xlink:type='arc' xlink:from='cs201' xlink:to='cs201desc'></arc>
</extendedlink>
<p><name xlink:type='simple'
      xlink:href='students/patjones62.xml'>Pat Jones</name>
is taking <course xlink:type='simple'
      xlink:href='#CS101'>CS-101</course>.</p>
<courselist>
<course id='CS101'>Computer Science 101</course>
<course id='CS201'>Computer Science 201</course>
</courselist>
</doc>

With the addition of an extended link element, the courses in the course list also become starting resources. Note that this makes the first course in the course list (identified in red and bold-italic) both a starting resource and an ending resource. This example could be complicated further by placing the extended link in a physically separate resource from the documents in question.

In order for links to be styled, they must be identified. The XLink-aware application must somehow provide additional information beyond what is explicitly marked up in the document available to the styling engine. This can be described in terms of Infoset contributions.

<xsd:schema targetNamespace="http://www.w3.org/2001/06/xml-link-style"
            elementFormDefault="qualified"
            xmlns:xsd="http://www.w3.org/2000/10/XMLSchema"
            xmlns:xlink="http://www.w3.org/1999/xlink"
            xmlns:link='http://www.w3.org/2001/06/xml-link-style'>
<xsd:complexType name='linkType'>
  <xsd:sequence minOccurs='1' maxOccurs='1'>
    <xsd:element ref='link:arc' minOccurs='1' maxOccurs='unbounded'/>
    <xsd:choice minOccurs='0' maxOccurs='unbounded'>
      <xsd:element name='xlink:title' type='opaqueType'/>
      <xsd:any namespace='##other' minOccurs='0' maxOccurs='unbounded'/>
    </xsd:choice>
  </xsd:sequence>
  <xsd:attribute name='type'>
    <xsd:simpleType>
      <xsd:restriction base='xsd:string'>
        <xsd:enumeration value='simple'/>
        <xsd:enumeration value='extended'/>
      </xsd:restriction>
    </xsd:simpleType>
  </xsd:attribute>
  <xsd:attribute name='role' type='xsd:uriReference'/>
  <xsd:attribute name='title' type='xsd:string'/>
  <xsd:anyAttribute namespace='##other' processContents='strict'/>
</xsd:complexType>
<xsd:element name='link' type='link:linkType'/>
</xsd:schema>

<xsd:schema targetNamespace="http://www.w3.org/2001/06/xml-link-style"
            elementFormDefault="qualified"
            xmlns:xsd="http://www.w3.org/2000/10/XMLSchema"
            xmlns:xlink="http://www.w3.org/1999/xlink"
            xmlns:link='http://www.w3.org/2001/06/xml-link-style'>
<xsd:complexType name='arcType'>
  <xsd:sequence minOccurs='1' maxOccurs='1'>
    <xsd:element ref='link:startParticipant'/>
    <xsd:element ref='link:endParticipant'/>
    <xsd:choice minOccurs='0' maxOccurs='unbounded'>
      <xsd:element name='xlink:title' type='opaqueType'/>
      <xsd:any namespace='##other' minOccurs='0' maxOccurs='unbounded'/>
    </xsd:choice>
  </xsd:sequence>
  <xsd:attribute name='role' type='xsd:uriReference'/>
  <xsd:attribute name='title' type='xsd:string'/>
  <xsd:attribute name='show'>
    <xsd:simpleType>
      <xsd:restriction base='xsd:string'>
        <xsd:enumeration value='new'/>
        <xsd:enumeration value='replace'/>
        <xsd:enumeration value='embed'/>
        <xsd:enumeration value='other'/>
        <xsd:enumeration value='none'/>
      </xsd:restriction>
    </xsd:simpleType>
  </xsd:attribute>
  <xsd:attribute name='actuate'>
    <xsd:simpleType>
      <xsd:restriction base='xsd:string'>
        <xsd:enumeration value='onLoad'/>
        <xsd:enumeration value='onRequest'/>
        <xsd:enumeration value='other'/>
        <xsd:enumeration value='none'/>
      </xsd:restriction>
    </xsd:simpleType>
  </xsd:attribute>
  <xsd:attribute name='target-stylesheet' type='xsd:uriReference'/>
  <xsd:attribute name='target-processing-context' type='xsd:uriReference'/>
  <xsd:attribute name='target-presentation-context' type='xsd:uriReference'/>
  <xsd:anyAttribute namespace='##other' processContents='strict'/>
</xsd:complexType>
</xsd:schema>

<xsd:schema targetNamespace="http://www.w3.org/2001/06/xml-link-style"
            elementFormDefault="qualified"
            xmlns:xsd="http://www.w3.org/2000/10/XMLSchema"
            xmlns:xlink="http://www.w3.org/1999/xlink"
            xmlns:link='http://www.w3.org/2001/06/xml-link-style'>
<xsd:complexType name='participantType'>
  <xsd:choice minOccurs='0' maxOccurs='unbounded'>
    <xsd:element name='xlink:title' type='opaqueType'/>
    <xsd:any namespace='##other' minOccurs='0' maxOccurs='unbounded'/>
  </xsd:choice>
  <xsd:attribute name='role' type='xsd:uriReference'/>
  <xsd:attribute name='title' type='xsd:string'/>
  <xsd:attribute name='resource' type='xsd:string'/>
  <xsd:anyAttribute namespace='##other' processContents='strict'/>
</xsd:complexType>
</xsd:schema>

<doc>
<a xlink:href="foo.xml"
      xlink:show="new" xlink:actuate="onRequest">Click here</a>
</doc>

<link>
  <arc show="new" actuate="onRequest">
    <startParticipant resource="/doc/a[1]"/>
    <endParticipant resource="foo.xml"/>
  </arc>
</link>

<doc>
<extendedlink xlink:type='extended'
      xlink:role='http://example.com/props/link1'>
  <loc xlink:type='locator' xlink:label='a' xlink:href='#a'></loc>
  <loc xlink:type='locator' xlink:label='b'
      xlink:role='http://example.com/props/loc1'
      xlink:href='#b1'></loc>
  <loc xlink:type='locator' xlink:label='b' xlink:href='#b2'></loc>
  <arc xlink:type='arc' xlink:from='a' xlink:to='b'
      xlink:arcrole='http://example.com/props/loc1'></arc>
</extendedlink>
<p><phrase id='a'>This</phrase> links to
<phrase id='b1'>this</phrase> and
<phrase id='b2'>this</phrase>.</p>
</doc>

<link role="http://example.com/props/link1">
  <arc role="http://example.com/props/loc1">
    <participant resource="#a"/>
    <participant resource="#b1" role="http://example.com/props/loc1"/>
  </arc>
  <arc role="http://example.com/props/loc1">
    <participant resource="#a"/>
    <participant resource="#b2"/>
  </arc>
</link>

2.2 XLink Traversal

Link traversal always involves exactly two participating resources. In the context of a styling application, it can have several possible results:

1. The document currently being presented may be replaced by the new resource identified as the ending resource of the traversal.

2. A new viewing context (window, frame, pane, etc.) may be created in which to present the ending resource of the traversal.

3. The ending resource may be styled and the styled result may be embedded within the document currently being presented (instead of, or perhaps in addition to, the starting resource).

4. Application-specific semantics outside the scope of this note.

In the context of styling, each of these operations can be considered a presentation or style issue. This is particularly the case since XLink linking elements leave the processing of the attributes controlling presentation (xlink:show and xlink:actuate) at the discretion of the application.

Consequently, we will address these issues under style.

3.1 With Current Technologies

Once the XLink-aware application has identified the information items that are participants in a link, styling the link becomes relatively straightforward. One can easily imagine an augmented CSS application or even a Perl script that made styling choices based upon the information obtained from the augmented Infoset.

Styling linking resources in XSL V1.0 can be achieved with small set of extension functions. The addition of a standard extension function API, anticipated for XSLT 1.1, makes this a practical solution for the present.

There are significant drawbacks to using extension functions for styling links, principal among them the fact that it places all of the burden on the stylesheet author. In order to handle links between arbitrary elements, every template would have to include conditional logic using the extension functions. This makes the extension function approach impractical as a long-term solution, but it is a solution that can be made to work today.

<xsl:template match="phrase[count(ext:arc-start()) > 0]">
  <-- If the phrase is part of a link, make it a link to the target
         of the first arc. This does not adequately handle the case where
         the phrase participates as the starting resource in more than
         one link. -->
  <fo:basic-link
      external-destination="{ext:arc-start()/endParticipant/@resource}">
    <xsl:apply-templates/>
  </fo:basic-link>
</xsl:template>

<xsl:template match="phrase">
  <xsl:apply-templates/>
</xsl:template>

3.2 With a Link-Aware XSLT Processor

[This section describes hypothetical additions to XSLT and/or XSL. These additions have not been reviewed by the WG and their presence here does not indicate that they will be added to any future version of XSL.]

In order to address the problems associated with placing all of the burden of link maintenance on the stylesheet author, we need to add XLink support into XSLT in a much more significant manner.

We observe that once the XSLT processor is aware of the link relationships that exist in the source document, it could conceivably maintain those relationships across transformation. Consider a simple document with a link from node B to node D:

During transformation, for every node in the result tree, the XSLT processor knows what the context node in the source tree was when the result node was created. It follows that XSLT can, in principle, maintain the link relationships across transformation.

Some difficulties need to be addressed:

1. How does the stylesheet author control the selection of links?

   Suppose that the source document links an element, A, in the source document with three other elements in the source document, B, C, and D. The XLink-aware processor can maintain that relationship in the result tree (linking A' with B', C', and D'), but what if the stylesheet author wishes to suppress the arc between A and C?

   We suggest two new top-level XSLT elements, xsl:strip-links and xsl:preserve-links, to provide this capability.

2. What happens if a source node is never processed, or produces no nodes in the result tree?

   If that source node is the sole participant at one end of an arc (or if all of the nodes in the participant resource have vanished), then that link does not occur in the result tree.

3. What happens if the source node is processed several times, producing disjoint nodes in the result tree?

   We observe that heuristics have been described for this case in [HookerMaden2000]. Since heuristics are known to be imperfect, we suggest a new boolean attribute, xsl:link-target, described below.

4. How do you add new links to the Link Set model?

   Modelling the links as Infoset augmentation has the appealing property that it allows all of the links to be processed in the same way. But what if the stylesheet wants to add new links that should also be processed in the same way?

   We propose new XSLT elements for this purpose, see 3.3 Style Elements.

The serializer for the result tree could instantiate the link relationships that it knows about using XLink, making this a nicely self-contained system: an XLink-aware XSLT processor produces a result tree that contains XLinks.

The problem of styling these links remains.

<!-- Category: instruction -->
<xsl:link-style
  select = expression
  xsl:use-attribute-sets = qnames>
  <!-- Content: xsl:attribute* -->
</xsl:link-style>

<xsl:link-style select="link::*/@role='http://www.w3.org/1999/xhtml'">
  <xsl:attribute name="color">blue</xsl:attribute>
  <xsl:attribute name="text-decoration">underlined</xsl:attribute>

<xsl:template match="*[count(arc-start::*) > 0]" priority="100">
  <table>
    <tr>
      <td>
        <xsl:next-match/>
      </td>
    </tr>
  </table>
</xsl:template>

<xsl:template match="*[arc-start::*]" priority="100">
  <-- If the element is part of a link, make it a link to the target
         of the first arc. This does not adequately handle the case where
         the phrase participates as the starting resource in more than
         one link. -->
  <fo:basic-link
      external-destination="{arc-start::*[1]/endParticipant/@resource}">
    <xsl:next-match/>
  </fo:basic-link>
</xsl:template>

<xsl:template match="phrase">
  <xsl:apply-templates/>
</xsl:template>

<xsl:template match="emphasis">
  <em><xsl:apply-templates/></em>
</xsl:template>

<!-- etc. -->

3.3 Style Elements

Our original goal in writing this note was to explore how linking and style effect each other and how a processing system might reasonably deal with these issues. Several early reviewers suggested that this work could be taken further to provide a mechanism not only for providing uniform treatment of source document links, but also uniform treatment of links created by the stylesheet. In this section, we explore some of those ideas.

Consider this simple document:

<doc>
<p><name>Pat Jones</name> is taking <course xlink:type='simple'
      xlink:href='courses/CS101.xml'>CS-101</course>.</p>
</doc>

Imagine for the moment that our goal is to link the persons name with some online address book. One way to do that would be to construct the link natively in the result tree vocabulary with a template like this (assuming our target is HTML):

<xsl:template match="name">
  <a href="http://example.com/address?{.}">
    <xsl:apply-templates/>
  </a>
</xsl:template>

But that has the unsatisfactory result that the link is unknown to the "link aware" processor we've been describing. That processor has already constructed a link set for the source document:

<linkset xmlns="&namespaceName;">
  <link>
    <arc>
      <startParticipant resource="/doc/p/course[1]"/>
      <endParticipant resource="courses/CS101.xml"/>
    </arc>
  </link>
</linkset>

What would seem more appropriate would be to insert the resulting link into the "result document link set". The result document link set is conceptually analagous to the source document link set: it describes the linking relationships in the result document.

Up to now, the result document link set has been discussed only implicitly because it was derived solely from the source document link set.

We introduce four new XSL elements for constructing links in the result tree link set: xsl:link, xsl:arc, xsl:start-participant, and xsl:end-participant.

<xsl:template match="name">
  <xsl:link>
    <xsl:arc>
      <xsl:start-participant select="."/>
      <xsl:end-participant resource="http://example.com/address?{.}"/>
    </xsl:arc>
  </xsl:link>
</xsl:template>

<div>
  <p><em>Pat Jones</em> is taking <span>CS 101<span></p>
</div>

<linkset xmlns="&namespaceName;">
  <link>
    <arc>
      <start-participant resource="result-tree:/div/p/span[1]"/>
      <end-participant resource="courses/cs101.xml"/>
    </arc>
  <link>

<linkset xmlns="&namespaceName;">
  <link>
    <arc>
      <start-participant resource="result-tree:/div/p/em[1]"/>
      <end-participant resource="http://example.com/address?Pam Jones"/>
    </arc>
  <link>

<xsl:template match="xref">
  <xsl:text>See also: </xsl:text>
  <xsl:apply-templates/>
</xsl:template>

<xsl:template match="xref">
  <xsl:text result-tree-id="xref{generate-id(.)}">See also: </xsl:text>
  <xsl:apply-templates/>
  <xsl:link>
    <xsl:arc>
      <xsl:start-participant select="result-tree:/id(xref{generate-id(.)}"/>
      <xsl:end-participant resource="whatever-is-appropriate"/>
    </xsl:arc>
  </xsl:link>
</xsl:template>

4.1 A Conceptual Model for Styling Link Traversal

From a styling perspective, link traversal requires the styling application to retrieve the document which contains the ending resource, style it, and present it. In addition, the ending resource may get special treatment. It might, for example, be shown in reverse video or the document view might be adjusted so that the ending resource appears at the top of the viewing context.

Displaying the styled result is a complex problem because links are between source documents, not between their styled results. Consider, for example, an XLink cross-reference:

See <xref xlink:type="simple" xlink:href="#ch5">Chapter 5</xref>

This link expresses a relationship between the text "Chapter 5" and the element with an ID of "ch5" elsewhere in the document. It provides no specific information about the formatted result that might be presented to the reader. Online, this might become a hypertext link to some other location whereas in print it might be rendered simply as a page number in parenthesis (or not at all).

The arbitrary nature of styling transformations can make this problem even more complex, as when the target in the source document is rendered in multiple locations in the presented result (See 5 Discontiguous Resources).

We may also want to consider how much of the document that contains the ending resource we wish to display. HTML browsers traditionally retrieve the entire resource and display it, moving the viewing context to the point where the ending resource occurs. In the case of XML documents, we may wish to have more control. We add one additional generalization to the conceptual model for this purpose.

Rather than presenting the entire resource, we might want to display a subresource within the document that is different from the subresource that is the ending resource of the link. For example, to style a link to a figure within a book, we might want to display the whole chapter that contains the figure:

<doc id='process'>
  <chap>...</chap>
  <chap>...</chap>
  <chap id='present'>
    <p>...</p>
    <figure id='target'>
      ...
    </figure>
    <p>...</p>
    <p>...</p>
  </chap>
  <chap>...</chap>
</doc>

In other words, we might wish to style a link by processing a whole document (in order to get chapter numbering correct, for example), present the third chapter in the user agent, and highlight the figure.

We describe this in terms of three distinct contexts, each identified by a URI reference (probably including an [XPointer] fragment identifier in most cases):

1. [Definition: The Processing Context of a link traversal is the resource (or portion of a resource) that is available to the style engine.]

   Informally, this is the tree that is available to the styling application. Usually this is the whole document.

2. [Definition: The Presentation Context of a link traversal is the resource (or portion of a resource) that is effectively the source resource to be styled.]

   In other words, the results of styling the [Presentation Context] is the content that is presented in the user agent. Often this is the whole document.

3. [Definition: The Target of a link traversal is the ending resource of the link. ]

These components, plus the stylesheet to be used, are present in the Infoset contributions described in 2.1.1 XLink Infoset Contributions. However, the current XLink specification does not provide standard ways to provide all of these components. Rather than request possibly contentious additions to XLink at this late date, we recommend using default values for several components.

For embedded resources, we recommend that the default processing and presentation contexts be the same as the target (see 6.2 Ranges that are Presentation Context). For resources displayed with "new" or "replace" semantics, we recommend that the default processing and presentation contexts be the whole document that contains the ending resource.

In any case, the application has considerable freedom in selecting the appropriate stylesheet. In some applications it may make sense to use the same stylesheet as the source document (particularly, perhaps, in the "embed" case); in others it may make sense to use the XML Stylesheet PI ([XML Stylesheet PI]) from the target document or some other application-specific selection.

Application-specific behavior can be modeled with extension metadata in the XLink linking elements. If useful subsets of this behavior become common, a future version of XLink may promote them to standard elements.

<doc>
<?xml-stylesheet href="style1.xsl" type="text/xsl"?>
<list>
<item>x xxxx</item>
<item>xxx xx xxxx</item>
<embed xlink:type="simple"
       xlink:show="embed" xlink:actuate="onLoad"
       xlink:href="doc2.xml#xpointer(//list[1]/item[2])"/>
<item>xxxxx</item>
</list>
</doc>

<doc>
<?xml-stylesheet href="style2.xsl" type="text/xsl"?>
<list>
<item>y yyyy</item>
<item>yyy yy yyy</item>
<item>yyyy</item>
</list>
</doc>

1. x xxxx
2. xxx xx xxxx
2. yyy yy yyy
4. xxxxx

1. x xxxx
2. xxx xx xxxx
ii. yyy yy yyy
4. xxxxx

<doc>
<?xml-stylesheet href="style1.xsl" type="text/xsl"?>
<list>
<item>x xxxx</item>
<item>xxx xx xxxx</item>
<item><embed xlink:type="simple"
       xlink:show="embed" xlink:actuate="onLoad"
       xlink:href="doc2.xml#xpointer(//list[1]/item[2]/node())"/>
</item>
<item>xxxxx</item>
</list>
</doc>

<list-block>
<list-item>
  <list-item-label><block>1.</block></list-item-label>
  <list-item-body><block>x xxxx</block></list-item-body>
</list-item>
<list-item>
  <list-item-label><block>2.</block></list-item-label>
  <list-item-body><block>xxx xx xxxx</block></list-item-body>
</list-item>
<list-item>
  <list-item-label><block>2.</block></list-item-label>
  <list-item-body><block>yyy yy yyy</block></list-item-body>
</list-item>
<list-item>
  <list-item-label><block>4.</block></list-item-label>
  <list-item-body><block>xxxxx</block></list-item-body>
</list-item>
</list-block>

<ol>
<li>x xxxx</li>
<li>xxx xx xxxx</li>
<li>yyy yy yyy</li>
<li>xxxxx</li>
</ol>

4.1.3 XInclude vs. XLink Embedding

The distinction between [XInclude] and [XLink] deserves special consideration.

At a high level, [XInclude] is similar to external entity references in [XML]. That is, the inclusion is done at or shortly after parsing, before style is applied. As you can see in the following figure, the element "E" is identified as an XInclude element and the content of the source tree is modified prior to styling:

Embedded XLinks, as we've described them, are handled during the styling process. When an embedded XLink is processed, the result of styling the ending resource of the link is merged into the result of styling the document into which it is embedded.

The decision about whether to use an [XInclude] or an embedded [XLink] is very dependent on the application. As a general rule, if the resource being embedded is from the same schema as the embedding document, and it will be styled with the same stylesheet, [XInclude] is probably a good choice. If the embedded document is from a different schema, or requires a different stylesheet, [XLink] is probably the right choice.

4.2 The Semantics of Nested Linking

The actuate axis of an XLink linking element has two standard, defined values, onRequest and onLoad. For links which have the onRequest semantics, style processing is straightforward: processing continues (possibly to completion) until a user event initiates the link.

For links which have the onLoad semantic, however, things are slightly more complicated. The styling application is expected to process these links during the styling process (effectively, "when the document is loaded").

There are several cases to consider:

An "onLoad" link with an xlink:show of "new"

The styling application should create a new viewing context (window, frame, pane, etc.) and display the ending resource of the link in that context.

An "onLoad" link with an xlink:show of "replace"

The styling application should replace the document currently being styled with the ending resource of the link.

The [XLink] specification says that the first such link in document order is the one that should be processed. However, because a styling application has the freedom to process the nodes of a document in any order, this definition seems restrictive. We recommend instead that it simply state that the first such link encountered should be processed. (Subsequent nodes will clearly not be processed since the original document is abandoned.) By extension, if the first link encountered has multiple arcs, the first arc should be processed.

Note:

The fact that this behavior can lead to infinite loops through one or more documents is a problem outside the scope of this note.

An "onLoad" link with an xlink:show of "embed"

The styling application should embed the result of styling the ending resource of the link in the current document.

The possibility of a resource that is being embedded containing an "onLoad" link must also be considered:

An "onLoad" link with an xlink:show of "new" encountered in a resource being embedded

The styling application should create a new viewing context (window, frame, pane, etc.) and display the ending resource of the link in that context.

In other words, if A embeds B which contains an onLoad/new link to C, the result will be B embedded in A in one viewing context and C in another viewing context.

An "onLoad" link with an xlink:show of "replace" encountered in a resource being embedded

The style processor should replace the resource being embedded with the result of styling the ending resource of the link.

In other words, if A embeds B which contains an onLoad/replace link to C, the result will be C embedded in A, with no trace of B.

An "onLoad" link with an xlink:show of "embed" encountered in a resource being embedded

The styling application should embed the result of styling the ending resource of the link in the current document.

In other words, if A embeds B which contains an onLoad/embed link to C, the result will be C embedded in B embedded in A.

5.1 Implementing Consistent Behavior

Some presentation systems implement special behaviors with respect to linking resources. For example, browsers may present links in a different color or speak them in a different tone of voice.

Often, discontiguous resources can be viewed as distinct. That is, a single resource consisting of three phrases can generally be treated like three resources, each consisting of a single phrase.

When this is not sufficient, for example, when the stylesheet author wishes to implement "mouse-over" highlighting of links and she wants discontiguous parts of the same link to be highlighted together, additional effort may be required.

The enhanced Infoset constructed by XLink identification, provides the raw materials from which such a feature could be implemented.

The XSL Formatting Objects include properties for selecting alternate presentations based on conditions. These properties, in conjunction with a presentation system that has access to the enhanced Infoset would allow an application to support this behavior.

Likewise for other presentation systems, access to the enhanced Infoset provides enough information to implement the required functionality.

5.2 Discontinuity Introduced by Styling

Transforming source documents for presentation may introduce discontinuities. For example, consider a link to a chapter title. In the document that contains the ending resource, that title is a single, unambiguous element. But when that document is styled, the chapter title may occur in several places (in the table of contents, on the chapter title page, and in a dozen cross references). Which one of these represents the ending resource?

No perfect algorithm for finding the target is readily apparent, but reasonable heuristics have been described [HookerMaden2000].

To the extent that it is practical, we think applications should provide users with access to all of the possible targets.

6.1 Styling Ranges in a Larger Presentation Context

Styling ranges (starting or ending resources expressed with XPointer ranges) in a larger context is problematic when the data model of the style language has a coarser granularity than the XML character. In particular, the XSLT 1.0 data model exposes text nodes, but not individual characters.

We propose that a reasonable processing model in this case is simply to style the smallest available node in the data model. For example, we expect ext:arc-start() to return a non-empty node set on every text node that contains one or more characters that are starting resources.

This will generally result in the "sloppy" application of style. For example,

<doc>
<p>Some text about Pat Jones that participates in a third
party link.</p>
</doc>

will be styled as if the link were:

<doc>
<p>Some text about Pat Jones that participates in a third
party link.</p>
</doc>

and

<doc>
<p>This text demonstrates
<emph>a link</emph> that spans a <emph>not well-formed</emph>
range.</p>
</doc>

will be styled as if the link were:

<doc>
<p>This text demonstrates
<emph>a link</emph> that spans a <emph>not well-formed</emph>
range.</p>
</doc>

If styling markup of this sort is a requirement for XSLT 2.0, as we think it is, then the data model of XSLT will have to be extended to include characters.

A few additional extension functions could be added which would offer a laborious solution to a subset of the range problems that can occur inside a text node through extensive use of the substring function. But it is not clear that any rational substring-based approach will handle all of the possible cases (e.g. discontiguous character ranges within a single text node that taken together form a linking resource).

6.2 Ranges that are Presentation Context

The problem of ranges in the presentation context is much more serious. When the presentation context is a range, a "sloppy" approach is unsuitable. If the link author requests that a specific range of the target document is to be presented, displaying more or or less than that range may be disastrous. Consider the case where a warning is accidentally lost or an adjacent range that has security implications is accidentally displayed.

The problem is especially troublesome when we consider embedded links. In the embedded case, we have suggested that the presentation context be the same as the target. If an embedded link uses ranges to point to a portion of a text node, it would be entirely unacceptable to embed the entire text node.

To tackle the difficult case introduced by ranges, we suggest that a subset of XPointer that did not include ranges would be a useful product. Such a subset could then be used as the data type for presentation context and show="embed" ending resources.

However, we suggest the following approach of "pruning" as a possible work-around for applications which must support presentation contexts that are defined in terms of ranges:

1. Identify the smallest contiguous set of whole information items which completely contains the resource in question:

   <doc> <p>This text demonstrates <emph>a link</emph> that spans a <emph>not well-formed</emph> range.</p> </doc>

2. Within this set, it is possible to identify three classes of information items:

   1. Those that are wholly within the range: e.g. all the character information items that occurs between the two emph elements.

   2. Those that are wholly outside the range: e.g. the character information items that comprise the string "-formed".

   3. Those that are partially within the range: e.g. the emph Element Information Items.

3. Remove all information items that are wholly outside the range:

   <emph>link</emph> that spans a <emph>not well</emph>

   In this example, only text was removed, but if additional elements had been included by the initial set of information items, they would have been removed as well.

The node set that remains after this process becomes both the presentation context and the processing context for the link.

It is necessary for the processing context to be restricted as well as the presentation context because there is no practical way, in the general case, under arbitrary transformation, for an application to trim the styled result to just the nodes that resulted from processing the target. The tree must be pruned before styling. We feel that this additional complication provides further evidence in favor of a range-free subset of XPointer.

6.3 Ranges and Glyph/Character Boundaries

Ranges can also be problematic if they have boundaries that occur at certain glyph and character locations.

Consider the following range:

<doc>
<p>...a brief history of flying machines.</p>
</doc>

In a visual presentation system, what is the extent of that link if the word "flying" begins with the "fl" ligature?

This problem is not limited to subtle issues of appropriate glyph selection for aesthetic purposes. In some Indic languages, for example, the actual order of the displayed glyphs may be different from the order of characters in the source. Similar problems occur in Thai, Arabic, and Hebrew, where the order and position of displayed glyphs depends on linguistic factors, not simply on the order of the characters in the source document.

It's unclear if there are any specific recommendations that can be made about this issue globally, except that avoiding character ranges, especially ranges that occur inside words, is probably best.