DRI Schema Reference

Back to contents

DRI Schema Reference Table of Contents

• Introduction
• DRI in Manakin
• Common Design Patterns
• Schema Overview
• Merging of DRI Documents
• Version Changes
• Element Reference

Digital Repository Interface (DRI) is a schema that governs the structure of a Manakin DSpace page when encoded as an XML Document. It determines what elements can be present in the Document and the relationship of those elements to each other. This reference document explains the purpose of DRI, provides a broad architectural overview, and explains common design patterns. The appendix includes a complete reference for elements used in the DRI Schema, a graphical representation of the element hierarchy, and a quick reference table of elements and attributes.

Introduction

This manual describes the Digital Repository Interface (DRI) as it applies to the DSpace digital repository and XMLUI Manakin based interface. DSpace XML UI is a comprehensive user interface system. It is centralized and generic, allowing it to be applied to all DSpace pages, effectively replacing the JSP-based interface system. Its ability to apply specific styles to arbitrarily large sets of DSpace pages significantly eases the task of adapting the DSpace look and feel to that of the adopting institution. This also allows for several levels of branding, lending institutional credibility to the repository and collections.

Manakin, the second version of DSpace XML UI, consists of several components, written using Java, XML, and XSL, and is implemented in Cocoon. Central to the interface is the XML Document, which is a semantic representation of a DSpace page. In Manakin, the XML Document adheres to a schema called the Digital Repository Interface (DRI) Schema, which was developed in conjunction with Manakin and is the subject of this guide. For the remainder of this guide, the terms XML Document, DRI Document, and Document will be used interchangeably.

This reference document explains the purpose of DRI, provides a broad architectural overview, and explains common design patterns. The appendix includes a complete reference for elements used in the DRI Schema, a graphical representation of the element hierarchy, and a quick reference table of elements and attributes.

The Purpose of DRI

DRI is a schema that governs the structure of the XML Document. It determines the elements that can be present in the Document and the relationship of those elements to each other. Since all Manakin components produce XML Documents that adhere to the DRI schema, The XML Document serves as the abstraction layer. Two such components, Themes and Aspects, are essential to the workings of Manakin and are described briefly in this manual.

The Development of DRI

The DRI schema was developed for use in Manakin. The choice to develop our own schema rather than adapt an existing one came after a careful analysis of the schema's purpose as well as the lessons learned from earlier attempts at customizing the DSpace interface. Since every DSpace page in Manakin exists as an XML Document at some point in the process, the schema describing that Document had to be able to structurally represent all content, metadata and relationships between different parts of a DSpace page. It had to be precise enough to avoid losing any structural information, and yet generic enough to allow Themes a certain degree of freedom in expressing that information in a readable format.

Popular schemas such as XHTML suffer from the problem of not relating elements together explicitly. For example, if a heading precedes a paragraph, the heading is related to the paragraph not because it is encoded as such but because it happens to precede it. When these structures are attempted to be translated into formats where these types of relationships are explicit, the translation becomes tedious, and potentially problematic. More structured schemas, like TEI or Docbook, are domain specific (much like DRI itself) and therefore not suitable for our purposes.

We also decided that the schema should natively support a metadata standard for encoding artifacts. Rather than encoding artifact metadata in structural elements, like tables or lists, the schema would include artifacts as objects encoded in a particular standard. The inclusion of metadata in native format would enable the Theme to choose the best method to render the artifact for display without being tied to a particular structure.

Ultimately, we chose to develop our own schema. We have constructed the DRI schema by incorporating other standards when appropriate, such as Cocoon's i18n schema for internationalization, DCMI's Dublin Core, and the Library of Congress's METS schema. The design of structural elements was derived primarily from TEI, with some of the design patterns borrowed from other existing standards such as DocBook and XHTML. While the structural elements were designed to be easily translated into XHTML, they preserve the semantic relationships for use in more expressive languages.

DRI in Manakin

The general process for handling a request in DSpace XML UI consists of two parts. The first part builds the XML Document, and the second part stylizes that Document for output. In Manakin, the two parts are not discrete and instead wrapped within two processes: Content Generation, which builds an XML representation of the page, and Style Application, which stylizes the resulting Document. Content Generation is performed by Aspect chaining, while Style Application is performed by a Theme.

Themes

A Theme is a collection of XSL stylesheets and supporting files like images, CSS styles, translations, and help documents. The XSL stylesheets are applied to the DRI Document to covert it into a readable format and give it structure and basic visual formatting in that format. The supporting files are used to provide the page with a specific look and feel, insert images and other media, translate the content, and perform other tasks. The currently used output format is XHTML and the supporting files are generally limited to CSS, images, and JavaScript. More output formats, like PDF or SVG, may be added in the future.

A DSpace installation running Manakin may have several Themes associated with it. When applied to a page, a Theme determines most of the pageís look and feel. Different themes can be applied to different sets of DSpace pages allowing for both variety of styles between sets of pages and consistency within those sets. The xmlui.xconf configuration file determines which Themes are applied to which DSpace pages (see the Configuration and Customization chapter for more information on installing and configuring themes). Themes may be configured to apply to all pages of specific type, like browse-by-title, to all pages of a one particular community or collection or sets of communities and collections, and to any mix of the two. They can also be configured to apply to a singe arbitrary page or handle.

Aspect Chains

Manakin Aspects are arrangements of Cocoon components (transformers, actions, matchers, etc) that implement a new set of coupled features for the system. These Aspects are chained together to form all the features of Manakin. Five Aspects exist in the default installation of Manakin, each handling a particular set of features of DSpace, and more can be added to implement extra features. All Aspects take a DRI Document as input and generate one as output. This allows Aspects to be linked together to form an Aspect chain. Each Aspect in the chain takes a DRI Document as input, adds its own functionality, and passes the modified Document to the next Aspect in the chain.

Common Design Patterns

There are several design patterns used consistently within the DRI schema. This section identifies the need for and describes the implementation of these patterns. Three patterns are discussed: language and internationalization issues, standard attribute triplet (id, n, and rend), and the use of structure-oriented markup.

Localization and Internationalization

Internationalization is a very important component of the DRI system. It allows content to be offered in other languages based on user's locale and conditioned upon availability of translations, as well as present dates and currency in a localized manner. There are two types of translated content: content stored and displayed by DSpace itself, and content introduced by the DRI styling process in the XSL transformations. Both types are handled by Cocoon's i18n transformer without regard to their origin.

When the Content Generation process produces a DRI Document, some of the textual content may be marked up with i18n elements to signify that translations are available for that content. During the Style Application process, the Theme can also introduce new textual content, marking it up with i18n tags. As a result, after the Theme's XSL templates are applied to the DRI Document, the final output consists of a DSpace page marked up in the chosen display format (like XHTML) with i18n elements from both DSpace and XSL content. This final document is sent through Cocoon's i18n transformer that translates the marked up text.

Standard attribute triplet

Many elements in the DRI system (all top-level containers, character classes, and many others) contain one or several of the three standard attributes: id, n, and rend. The id and n attributes can be required or optional based on the elementís purpose, while the rend attribute is always optional. The first two are used for identification purposes, while the third is used as a display hint issued to the styling step.

Identification is important because it allows elements to be separated from their peers for sorting, special case rendering, and other tasks. The first attribute, id, is the global identifier and it is unique to the entire document. Any element that contains an id attribute can thus be uniquely referenced by it. The id attribute of an element can be either assigned explicitly, or generated from the Java Class Path of the originating object if no name is given. While all elements that can be uniquely identified can carry the id attribute, only those that are independent on their context are required to do so. For example, tables are required to have an id since they retain meaning regardless of their location in the document, while table rows and cells can omit the attribute since their meaning depends on the parent element.

The name attribute n is simply the name assigned to the element, and it is used to distinguish an element from its immediate peers. In the example of a particular list, all items in that list will have different names to distinguish them from each other. Other lists in the document, however, can also contain items whose names will be different from each other, but identical to those in the first list. The n attribute of an element is therefore unique only in the scope of that elementís parent and is used mostly for sorting purposes and special rendering of a certain class of elements, like, for example, all first items in lists, or all items named "browse". The n attribute follows the same rules as id when determining whether or not it is required for a given element.

The last attribute in the standard triplet is rend. Unlike id and n, the rend attribute can consist of several space delimited values and is optional for all elements that can contain it. Its purpose is to provide a rendering hint from the middle layer component to the styling theme. How that hint is interpreted and whether it is used at all when provided, is completely up the theme. There are several cases, however, where the content of the rend attribute is outlined in detail and its use is encouraged. Those cases are the emphasis element hi, the division element div, and the list element. Please refer to the Element Reference for more detail on these elements.

Structure-oriented markup

The final design pattern is the use of structure-oriented markup for content carried by the XML Document. Once generated by Cocoon, the Document contains two major types of information: metadata about the repository and its contents, and the actual content of the page to be displayed. A complete overview of metadata and content markup and their relationship to each other is given in the next section. An important thing to note here, however, is that the markup of the content is oriented towards explicitly stating structural relationships between the elements rather than focusing on the presentational aspects. This makes the markup used by the Document more similar to TEI or Docbook rather than HTML. For this reason, XSL templates are used by the themes to convert structural DRI markup to XHTML. Even then, an attempt is made to create XHTML as structural as possible, leaving presentation entirely to CSS. This allows the XML Document to be generic enough to represent any DSpace page without dictating how it should be rendered.

Schema Overview

The DRI XML Document consists of the root element document and three top-level elements that contain two major types of elements. The three top-level containers are meta, body, and options. The two types of elements they contain are metadata and content, carrying metadata about the page and the contents of the page, respectively. Figure 1 depicts the relationship between these six components.

Figure 1: The two content types across three major divisions of a DRI page.

The document element is the root for all DRI pages and contains all other elements. It bears only one attribute, version, that contains the version number of the DRI system and the schema used to validate the produced document. At the time of writing the working version number is "1.1".

The meta element is a the top-level element under document and contains all metadata information about the page, the user that requested it, and the repository it is used with. It contains no structural elements, instead being the only container of metadata elements in a DRI Document. The metadata stored by the meta element is broken up into three major groups: userMeta, pageMeta, and objectMeta, each storing metadata information about their respective component. Please refer to the reference entries for more information about these elements.

The options element is another top-level element that contains all navigation and action options available to the user. The options are stored as items in list elements, broken up by the type of action they perform. The five types of actions are: browsing, search, language selection, actions that are always available, and actions that are context dependent. The two action types also contain sub-lists that contain actions available to users of varying degrees of access to the system. The options element contains no metadata elements and can only make use of a small set of structural elements, namely the list element and its children.

The last major top-level element is the body element. It contains all structural elements in a DRI Document, including the lists used by the options element. Structural elements are used to build a generic representation of a DSpace page. Any DSpace page can be represented with a combination of the structural elements, which will in turn be transformed by the XSL templates into another format. This is the core mechanism that allows DSpace XML UI to apply uniform templates and styling rules to all DSpace pages and is the fundamental difference from the JSP approach currently used by DSpace.

The body element directly contains only one type of element: div. The div element serves as a major division of content and any number of them can be contained by the body. Additionally, divisions are recursive, allowing divs to contain other divs. It is within these elements that all other structural elements are contained. Those elements include tables, paragraph elements p, and lists, as well as their various children elements. At the lower levels of this hierarchy lie the character container elements. These elements, namely paragraphs p, table cells, lists items, and the emphasis element hi, contain the textual content of a DSpace page, optionally modified with links, figures, and emphasis. If the division within which the character class is contained is tagged as interactive (via the interactive attribute), those elements can also contain interactive form fields. Divisions tagged as interactive must also provide method and action attributes for its fields to use.

Figure 2: All the elements in the DRI schema.

Note: This image is out-of-date, it does not reflect the changes between 1.0 and 1.1 such as reference and referenceSet.

Merging of DRI Documents

Having described the structure of the DRI Document, as well as its function in Manakin's Aspect chains, we now turn our attention to the one last detail of their use: merging two Documents into one. There are several situations where the need to merge two documents arises. In Manakin, for example, every Aspect is responsible for adding different functionality to a DSpace page. Since every instance of a page has to be a complete DRI Document, each Aspect is faced with the task of merging the Document it generated with the ones generated (and merged into one Document) by previously executed Aspects. For this reason rules exist that describe which elements can be merged together and what happens to their data and child elements in the process.

When merging two DRI Documents, one is considered to be the main document, and the other a feeder document that is added in. The three top level containers (meta, body and options) of both documents are then individually analyzed and merged. In the case of the options and meta elements, the children tags are taken individually as well and treated differently from their siblings.

The body elements are the easiest to merge: their respective div children are preserved along with their ordering and are grouped together under one element. Thus, the new body tag will contain all the divs of the main document followed by all the divs of the feeder. However, if two divs have the same n and rend attributes (and in case of an interactive div the same action and method attributes as well), those divs will be merged into one. The resulting div will bear the id, n, and rend attributes of the main document's div and contain all the divs of the main document followed by all the divs of the feeder. This process continues recursively until all the divs have been merged. It should be noted that two divisions with separate pagination rules cannot be merged together.

Merging the options elements is somewhat different. First, list elements under options of both documents are compared with each other. Those unique to either document are simply added under the new options element, just like divs under body. In case of duplicates, that is list elements that belong to both documents and have the same n attribute, the two lists will be merged into one. The new list element will consist of the main documentís head element, followed label-item pairs from the main document, and then finally the label-item pairs of the feeder, provided they are different from those of the main.

Finally, the meta elements are merged much like the elements under body. The three children of meta - userMeta, pageMeta, and objectMeta - are individually merged, adding the contents of the feeder after the contents of the main.

Version Changes

The DRI schema will continue to evolve overtime as the needs of interface design require. The version attribute on the document will indicate which version of the schema the document conforms to. At the time Manakin was incorporated into the standard distribution of DSpac the current version was "1.1", however earlier versions of the Manakin interface may use "1.0".

Changes from 1.0 to 1.1

There were major structural changes between these two version numbers. Several elements were removed from the schema:includeSet, include, objectMeta, and object. Originaly all metadata for objects were included in-line with the DRI document, this proved to have several problems and has been removed in version 1.1 of the DRI schema. Instead of including metadata in-line, external references to the metadata is included. Thus, a reference element has been added along with referenceSet. These new elements operate like their counterparts in the previous version except refrencing metadata contained on the objectMeta element they reference metadata in external files. The repository and repositoryMeta elements were alse modified in a similar mannor removing in-line metadata and refrencing external metadata documents.

Element Refenence

<document version=1.0>
  <meta> ... </meta>
  <body>
    <div n="division-example1" id="XMLExample.div.division-example1">
     ... 
    </div>
    <div n="division-example2" id="XMLExample.div.division-example2" interactive="yes" action="www.DRItest.com" method="post">
     ...
    </div>
     ...
  </body>
  <options> ... </options>
</document>

<table n="table-example" id="XMLExample.table.table-example" rows="2" cols="3">
    <row role="head">
      <cell cols="2">Data Label One and Two</cell>
      <cell>Data Label Three</cell>
      ...
    </row>
    <row>
      <cell> Value One </cell>
      <cell> Value Two </cell>
      <cell> Value Three </cell>
      ...
    </row>
    ...
</table>

<body>
    <div n="division-example" id="XMLExample.div.division-example">
      <head> Example Division </head>
      <p> This example shows the use of divisions. </p>
      <table ...>
        ...
      </table>
      <referenceSet ...>
        ...
      </referenceSet>
      <list ...>
        ...
      </list>
      <div n="sub-division-example" id="XMLExample.div.sub-division-example">
        <p> Divisions may be nested </p>
        ...
      </div>
      ...
    </div>
    ...
</body>

<document version="1.0">
    <meta>
      ...
    </meta>
    <body>
      ...
    </body>
    <options>
      ...
    </options>
</document>

<p>
  <hi> ... </hi>
  <xref> ... </xref>
  <figure> ... </figure>
  ...
  <field id="XMLExample.field.name" n="name" type="text" required="yes">
    <params size="16" maxlength="32"/>
    <help>Some help text with <i18n>localized content</i18n>.</help>
    <value type="raw">Default value goes here</value>
  </field>
</p>
        

<p>
    <hi> ... </hi>
    ...
    <xref> ... </xref>
    ...
    <field> ... </field>
    ...
    <figure source="www.example.com/fig1"> This is a static image. </figure>
    <figure source="www.example.com/fig1" target="www.example.net">
      This image is also a link.
    </figure>
    ...
</p>

<div ...>
    <head> This is a simple header associated with its div element. </head>
    <div ...>
      <head rend="green"> This header will be green. </head>
      <p>
        <head> A header with <i18n>localized content</i18n>. </head>
        ...
      </p>
    </div>
    <table ...>
      <head> ... </head>
      ...
    </table>
    <list ...>
      <head> ... </head>
      ...
    </list>
    ...
</body>

<p>
    <hi> ... </hi>
    ...
    <xref> ... </xref>
    ...
    <figure> ... </figure>
    ...
    <field id="XMLExample.field.name" n="name" type="text" required="yes">
      <params size="16" maxlength="32" />
      <help>Some help text with <i18n>localized content</i18n>.</help>
    </field>
    ...
</p>

<p>
    This text is normal, while <hi rend="bold">this text is bold and this text is <hi rend="italic">bold and italic.</hi></hi>
</p>

Example needed.

<list n="list-example" id="XMLExample.list.list-example">
  <head> Example List </head>
  <item> This is the first item  </item>
  <item> This is the second item with <hi ...>highlighted text</hi>, <xref ...> a link</xref> and an <figure ...>image</figure>.</item>
  ...
  <list n="list-example2" id="XMLExample.list.list-example2">
    <head> Example List </head>
    <label>ITEM ONE:</label>
    <item> This is the first item  </item>
    <label>ITEM TWO:</label>
    <item> This is the second item with <hi ...>highlighted text</hi>, <xref ...> a link</xref> and an <figure ...>image</figure>.</item>
    <label>ITEM THREE:</label>
    <item> This is the third item with a <field ...> ... </field> </item>
    ...
  </list>
  <item> This is the third item in the list </item>
  ...
</list>

<list n="list-example" id="XMLExample.list.list-example">
  <head>Example List</head>
  <label>1</label>
  <item> This is the first item  </item>
  <label>2</label>
  <item> This is the second item with <hi ...>highlighted text</hi>, <xref ...> a link</xref> and an <figure ...>image</figure>.</item>
  ...
  <list n="list-example2" id="XMLExample.list.list-example2">
    <head>Example Sublist</head>
    <label>ITEM ONE:</label>
    <item> This is the first item  </item>
    <label>ITEM TWO:</label>
    <item> This is the second item with <hi ...>highlighted text</hi>, <xref ...> a link</xref> and an <figure ...>image</figure>.</item>
    <label>ITEM THREE:</label>
    <item> This is the third item with a <field ...> ... </field> </item>
    ...
  </list>
  <item> This is the third item in the list </item>
  ...
</list>

<div ...>
  ...
  <list n="list-example" id="XMLExample.list.list-example">
    <head>Example List</head>
    <item> ... </item>
    <item> ... </item>
    ...
    <list n="list-example2" id="XMLExample.list.list-example2">
      <head>Example Sublist</head>
      <label> ... </label>
      <item> ... </item>
      <label> ... </label>
      <item> ... </item>
      <label> ... </label>
      <item> ... </item>
      ...
    </list>
    <label> ... </label>
    <item> ... </item>
    ...
  </list>
</div>

<document version=1.0>
  <meta>
    <userMeta> ... </userMeta>
    <pageMeta> ... </pageMeta>
    <repositoryMeta> ... </repositoryMeta>
  </meta>
  <body> ... </body>
  <options> ... </options>
</document>

<meta>
  <userMeta>
    <metadata element="identifier" qualifier="firstName"> Bob </metadata>
    <metadata element="identifier" qualifier="lastName"> Jones </metadata>
    <metadata ...> ... </metadata>
    ...
  </userMeta>
  <pageMeta>
    <metadata element="rights" qualifier="accessRights">user</metadata>
    <metadata ...> ... </metadata>
    ...
  </pageMeta>
</meta>

<document version=1.0>

    <meta> Ö </meta>

    <body> Ö </body>

    <options>

        <list n="navigation-example1" id="XMLExample.list.navigation-example1">

            <head>Example Navigation List 1</head>

            <item><xref target="/link/to/option">Option One</xref></item>

            <item><xref target="/link/to/option">Option two</xref></item>

           	...

        </list>

        <list n="navigation-example2" id="XMLExample.list.navigation-example2">

            <head>Example Navigation List 2</head>

            <item><xref target="/link/to/option">Option One</xref></item>

            <item><xref target="/link/to/option">Option two</xref></item>

            ...

        </list>

        ...

    </options>

</document>

<div n="division-example" id="XMLExample.div.division-example">

    <p> This is a regular paragraph. </p>

    <p> This text is normal, while <hi rend="bold">this text is bold and this  

      text is <hi rend="italic">bold and italic.</hi></hi> 

    </p>

    <p> This paragraph contains a <xref target="/link/target">link</xref>, a  

      static <figure source="/image.jpg">image</figure>, and a <figure target=

      "/link/target" source="/image.jpg">image link.</figure>

    </p>

</div>

<meta>

    <userMeta> ... </userMeta>

    <pageMeta>

        <metadata element="title">Examlpe DRI page</metadata>

        <metadata element="contextPath">/xmlui/</metadata>

        <metadata ...> ... </metadata>

        ...

        <trail source="123456789/6"> A bread crumb item </trail>

        <trail ...> ... </trail>

        ...

    </pageMeta>

</meta>

<p>

    <field id="XMLExample.field.name" n="name" type="text" required="yes">

        <params size="16" maxlength="32"/>

        <help>Some help text with <i18n>localized content</i18n>.</help>

        <default>Default value goes here</default>

    </field>

</p>

            <includeSet n="browse-list" id="XMLTest.includeSet.browse-list">
            <refrence url="/metadata/handle/123/4/mets.xml" repositoryID="123" type="DSpace Item"/>
            <refrence url="/metadata/handle/123/5/mets.xml" repositoryID="123" />
            ...
            </includeSet>
          

            <div ...>
            <head> Example Division </head>
            <p> ... </p>
            <table> ... </table>
            <list>
            ...
            </list>
            <referenceSet n="browse-list" id="XMLTest.referenceSet.browse-list" type="summaryView" informationModel="DSpace">
            <head>A header for the includeset</head>
            <refrence url="/metadata/handle/123/34/mets.xml"/>
            <refrence url=""metadata/handle/123/34/mets.xml/>
            </referenceSet>
            ...
            </p>

<repositoryMeta>

    <repository repositoryID="123456789" url="/metadata/handle/1234/4/mets.xml" />

</repositoryMeta>

<meta>

  <userMeta> ... </usermeta>

  <pageMeta> ... </pageMeta>

    <repositoryMeta>

        <repository repositoryIID="..." url="..." />

    </repositoryMeta>

</meta>

<table n="table-example" id="XMLExample.table.table-example" rows="2" cols="3">

    <row role="head">

      <cell cols="2">Data Label One and Two</cell>

        <cell>Data Label Three</cell>

        ...

    </row>

    <row>

      <cell> Value One </cell>

      <cell> Value Two </cell>

      <cell> Value Three </cell>

      ...

    </row>

    ...

</table>

<div n="division-example" id="XMLExample.div.division-example">

    <table n="table1" id="XMLExample.table.table1" rows="2" cols="3">

        <row role="head">

          <cell cols="2">Data Label One and Two</cell>

            <cell>Data Label Three</cell>

            ...

        </row>

        <row>

          <cell> Value One </cell>

          <cell> Value Two </cell>

          <cell> Value Three </cell>

          ...

        </row>

        ...

    </table>
    ...
</div>

<pageMeta>

    <metadata element="title">Examlpe DRI page</metadata>

    <metadata element="contextPath">/xmlui/</metadata>

    <metadata ...> ... </metadata>

    ...

    <trail target="/myDSpace"> A bread crumb item pointing to a page. </trail>

    <trail ...> ... </trail>

    ...

</pageMeta>

<meta>

    <userMeta>

        <metadata element="identifier" qualifier="email"> 

           bobJones@tamu.edu

        </metadata>

        <metadata element="identifier" qualifier="firstName"> Bob </metadata>

        <metadata element="identifier" qualifier="lastName"> Jones </metadata>

        <metadata element="rights" qualifier="accessRights">user</metadata>

        <metadata ...> ... </metadata>

        ...

        <trail source="123456789/6"> A bread crumb item </trail>

        <trail ...> ... </trail>

        ...

    </userMeta>

    <pageMeta> ... </pageMeta>

</meta>

<p>
  <hi> ... </hi>
  <xref> ... </xref>
  <figure> ... </figure>
  <field id="XMLExample.field.name" n="name" type="text" required="yes">
    <params size="16" maxlength="32"/>
    <help>Some help text with <i18n>localized content</i18n>.</help>
    <value type="default">Author, John</value>
  </field> 
</p>
        

<p>

    <xref target="/url/link/target">This text is shown as a link.</xref>

</p>