DITA : Villa

A "Mini-Home" Type in Darwin Information Typing Architecture

Abstract

In 2000, Dr. Ellen McDaniel and I began working on a new web site for the College of Engineering. A lot of innovations and ideas came out of the project, but one of the more innovative approaches that came from this design cycle was the beginning of the "mini-home" concept.

The idea for a mini-home is simple, it is a collection of important links pertaining to a subject. It is similar to a site map, though very condensed. There is not really anything special about a mini-home, as it is just a small group of links. Despite this it is a very powerful tool because it provides the all important table of contents function in a web compatible format. Another useful trait of mini-homes is that when the are bundled together in groups of similarly organized links, these mini-homes become a sort of online catalog of links.

Building on the original concept more sophisticated mini-homes can be context sensitive and even include non-link information, such as a summary or description of the mini-home's topic. To fully harness the power of mini-homes in the next design cycle of the college home page Ellen and I have decided to develop mini-homes in a semantically rich structure. We have chosen to develop a specialization of the DITA Topic to represent this information.

Structure of the Villa

The primary function of a mini-home (from now on, I will refer to it as the villa type) is a useful list of links. Since the list varies from topic to topic there is no consistent structure aside from the main link which is called the "homepage link". The villa type has a specialized body that contains one required homepage tag. It would be ideal for the text of this link to always be "Homepage" so it should be an empty tag, but if not it would require CDATA. After the homepage tag any combination of page or pagegroup tags should be allowed. Inside of pagegroup a pagegroup-name tag is optional (but highly recommended) to label the group. The page and pagegroup-name tags should require CDATA for contents since they are external and their titles would not likely be available to the parser.

Villas cannot be nested. They are based on topics and nesting villas in the way topics were intended to be nested would not allow them to be mixed with page links. It would also be important to know if a link was going to a real page or another villa, otherwise users could appear trapped in a site where all the pages only had links to other pages. For this reason the villapage tag was created and it can appear anywhere a page tag can. This tag could be rendered using the DITA title or one provided and give a link to the homepage of the villa as well as the rendered villa itself.

<dita>
  <villa id="123">
    <title></title>
    <titlealts></titlealts>
    <shortdesc></shortdesc>
    <prolog></prolog>
    <villa-body>
      <homepage href=""/> // a type of xref
      <page href="">Link Title</page> // a type of xref
      <villapage href=""/> // a type of xref
      <pagegroup>//a type of sl
        <pagegroup-name>Group Name</pagegroup-name> // a type of sli
        <page href="">Link Title</page> // a type of xref
        <villapage href=""/> // a type of xref
      </pagegroup>
    </villa-body>
    <related-links></related-links>
  </villa>
</dita>

Selection Rationale

I decided to encapsulate the links for a villa in a specialized body of the document type and not the related-links tag. This was a hard decision over not using a body tag (at all) and specializing the related-links tag instead. In the end it seemed to make more sense this way. Later, if other content is needed for a villa type, villa-body can be further specialized for different types of villas by allowing optional tags for such content. Also it would be a pain to have to deal specializing related-links. From what I understand of DITA, it can be done, but since the XSLT generates links based on the contents of the related-links tag it would be more limiting to do it this way because specializing the tags inside would likely break the linking features. I don't think generating html for related links works the same way as generating html for the tags that are body elements. Specialization support so far has been focused on the body content.