DITA Open Toolkit (OT) release 1.4 is a major release to add new and improved functionality, fulfill new requirements, and fix bugs. The single major theme of DITA OT 1.4 is support of the DITA 1.1 standard, which was approved by OASIS on August 13, 2007. DITA 1.1 has two major themes:

• Book deliverables (revision of the demo bookmap specialization in prior releases)
  
  • Book-level processing
  • Indexing capabilities, including see, see also, sort order, and page range
  • Graphic scaling improvements
  • Glossary-related elements
  • A new >abstract> element family, which also includes the <shortdesc> element from prior releases
• Data extensibility
  
  • New attributes and improved attribute behavior
  • A <foreign> element to support foreign content vocabularies like MathML and SVG
  • An <unknown> element for other unanticipated non-DITA content
  • A new <data> element

Book-level processing: General updates

• Consistent support for generated and user-defined lists (for example, table of contents, tables, figures, abbreviations, glossary, index, and bibliography)
• Documentation types (for example, reference manual and user guide)

Book-level processing: Specific updates

• Book <title> element, and division of the title into "library" and "title"
• xNAL compatibility with naming conventions

  Release 1.4 provides a transformational equivalence between bookmap and xNAL (extensible Name and Address Language, an OASIS standard) definitions for names and addresses. This equivalence enables XML-aware tools in workflow systems to capture and manipulate DITA bookmap names and addresses in a standard way.

• Special notices section at the front of the document
• New group of navigation list element to specify the addition of automated or compiled content lists for document navigation (table of contents, figures, and tables)
• Additional address elements (for example, <postalcode>)
• Additional element for organization and name (for example, <emailaddress>, <contactnumber>)

Additions include the following new elements and element families:

• <index-base>

  Common element that enables indexing specializations (both standard and user-defined). With this new functionality index generators can handle indexing elements they understand while filtering out those they cannot handle. A new indexing domain <indexing-d> accommodates the specializations of <index-base>.

• <index-see>
  Example (source):

  
  <indexterm>Carassius auratus
  <index-see>Goldfish</index-see>
  </indexterm>			
  				

  Example (output):

  
  Carassius auratus, 
  see Goldfish
  				

• <index-see-also>
  Example (source):

  
  <indexterm>Carp
  <index-see-also>Goldfish</index-see-also>
  </indexterm>			
  				

  Example (output):

  
  Carp, 56
    
  see also Goldfish
  				

• <index-sort-as>

  One common use for this functionality is an index that contains special characters at the beginning of what would otherwise be text entries (for example, the DITA tag <title>, which you want to be listed in the "t" section of the index rather than with the special characters.

  Example (source):

  
  <indexterm>&lt;title&gt;
  <index-sort-as>title</index-sort-as>
  </indexterm>
  				

• Index ranges using the start and end attributes of <indexterm>
  These new attributes would be used where a text discussion extends over more than one page. In Toolkit 1.4, you implement this feature by including the "start" attribute at the beginning of the discussion, and the "end" attribute at the end of the discussion.

  Note: Indexed ranges in DITA cannot span topics.
  Example (source):

  
  <indexterm start="level-1-goldfish">goldfish</indexterm>
  . . .
  <indexterm end="level-1-goldfish"/>
  				

  Note: The ellipsis represents content that may span several pages, as shown in the output example.

  Example (output):

  
  goldfish, 34-36
  				

In release 1.4, users can specify:

• A percentage value to which to scale the intrinsic size of the image
• An absolute value using a numeric value and one of the following units of measure: px (pixels, the default value), pc (picas), pt (points), in (inches), cm (centimeters), mm (millimeters), and em (ems)

.

The DITA 1.1 specification and Toolkit 1.4 implementation meet the core publishing requirements for books and online deliverables:

• Publishing a glossary listing in the back of a book
• Offering inline definitions in a help system or website
• Guiding authors to use consistent terminology by providing a controlled vocabulary during content creation

Putting each glossary definition in a separate topic is better suited for translation because terms that are the same in one language may be different in others. Therefore, glossary definitions should be collated based on the translated terms rather than assuming that a term will have the same set of definitions in all languages.

Example (source):

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE glossentry PUBLIC "-//OASIS//DTD DITA Glossary//EN" "../dtd/glossary.dtd">
<glossary>
<glossentry id="ddl">
<glossterm>Data Definition Language</glossterm>
<glossdef>A language used for defining databases . . .</glossdef>
</glossentry>
</glossary>
			

Example 1

<topic>
<title>My title</title>
<shortdesc>
Short description that is also the preview paragraph.
</shortdesc>
<body>
. . .
</body>
</topic>
				

Example 2

<topic>
<title>My title</title>
<abstract>
<p>
Paragraph in an abstract.
</p>
<shortdesc>
Short description in the abstract, also the preview.
</shortdesc>
</abstract>
<body>
. . .
</body>
</topic>

				

In release 1.4 of the Toolkit, a DITA information architect or developer can incorporate new conditional processing attributes for filtering and flagging, or new attributes with no existing equivalent that can be managed and generalized in the same way as conditional processing attributes in prior releases. These new attributes are:

• Identified as conditional processing attributes (when intended for this purpose)
• Preserved during generalization and respecialization
• While generalized, are still operable on by either general or specialized behaviors (for example, conditional processing)

The new attributes and improved attribute behavior is useful in the following ways:

• Generic attributes. A DITA information architect or developer adds a new attribute that has no equivalent in standard DITA, for example a phase attribute ( phases.mod) that identifies what phase of a process an element is associated with. To accomplish this, the architect or developer would express the new attribute as a separate domain package, integrate the domain package into the authoring DTDs or schemas, and supply processing behavior for the new attribute and ensure that it works on both the specialized form (phase="develop") and the generalized form (phase(develop)), using the conditional processing match logic as a pattern.
• Negative values. In DITA OT 1.4 you can set a new value in the ditaval that indicates processing should filter out unknown values. For example, in prior releases, if you had audiences A, B, and C, they were all included by default. You can now exclude one or more by default. If audience C is defined and included, the unspecified values A and B can be excluded.

Example (use of mathML inside a DITA file)

. . . as in the formula
<mathML>
<mml:math display="block">
<mml:mrow>
<mml:mo>&sum;</mml:mo>
<mml:mn>4</mml:mn>
<mml:mo>+</mml:mo>
<mml:mi>x</mml:mi>
</mml:mrow>
</mml:math>
<mathMLAlternate>4 + x</mathMLAlternate>
<mathML>.
</p>
			

Current and potential future uses of the <data> element include:

• The API Reference specialization (an announced work-in-progress at IBM) is being updated to use the <data> element to model complex application interfaces.
• The definition of a complex envelope for any application in which human-readable content is a payload is now possible.
• A library of specialized <data> elements to be used as building blocks for transactional documents could be produced.

Example (source code delimiters for automatic refresh of a code fragment, where the <sourceFile>, <startDelimiter>, and <endDelimiter> elements are specialized from <data>, but <codeFragment> is specialized from <codeblock>).

<example>
<title>An important coding technique</title>
<codeFragment>
<sourceFile value="helloWorld.java"/>
<startDelimiter value="FRAGMENT_START_1"/>
<endDelimiter value="FRAGMENT_END_1"/>
. . .
</codeFragment>
</example>
			

Example (real estate property for a house description, where the <realEstateProperty> and everything it contains are specialized from <data> but <houseDescription> is specialized from <section>).

<houseDescription>
<title>A great home for sale>
<realEstateProperty>
<realEstateBlock value="B7"/>
<realEstateLot value="4003"/>
. . . 
</realEstateProperty>
<p>This elegant property . . .</p>
<object data=""B7_4003_tour360Degrees.swf"/>
</houseDescription>
			

Example (identifies the maintainer of the topic, where <maintainer> is specialized from <data>).

<topicref href=""sometopic.dita">
<topicmeta>
<maintainer>George<maintainer>
</topicmeta>
. . .
</topicref>