Changes from DITA 1.1 to DITA 1.2

Darwin Information Typing Architecture (DITA) Version 1.2

(Non-normative) DITA 1.2 adds a number of new features to DITA, including indirect addressing via map-defined keys; the ability to define content-model constraints for DITA document types; specializations for learning content and the machine industry; and taxonomies, ontologies, and controlled vocabularies. Other refinements include extended markup for glossaries and terminology.

New features

The following features are new in DITA 1.2:
  • Keys and key references. See Key-based addressing.
  • Constraint modules. Constraint modules allow base content models to be further constrained without the need for specialization. For example, a constraint module can make optional elements required or disallow optional elements in a specific content model. See Constraint domains.
  • Topic and map specializations for learning and training information, including interactive assessments. See the architectural specification for learning and training content.
  • New elements for use with glossary entry topics for more complete description of terms, definition of acronyms, and so on.
  • New map specialization for defining controlled vocabularies and taxonomies. See subjectScheme.
  • New machine-industry task specialization. See Machinery task topic.

New element types

The following base element types are new in DITA 1.2:
<text>
Allowed in most contexts where text is allowed but neither <ph> nor <keyword> are allowed. Enables reuse of text in almost any context.
<bodydiv>
Allows creation of untitled containers within topic bodies. Intended primarily for specialization.
<sectiondiv>
Allows creation of untitled containers within sections. Intended primarily for specialization.
<keydef>
Topicref specialization for defining keys. Sets the default value for the @processing-role attribute to "resource-only".
<mapref>
Topicref specialization for referring to DITA maps. Sets the default value for the @format attribute to "ditamap".
<topicset>
Used to define sets of topicrefs that represent an atomic unit of reusable navigation structure. Requires the @id attribute be specified.
<topicsetref>
References a <topicset> element. Enables preservation of the identity of the referenced topicset.
<anchor>
Defines a point within a map to which topicrefs can be bound using the <anchorref> element.
<anchorref>
"Pushes" one or more topicrefs onto an anchor point defined by an <anchor> element. Similar to a conref push but allows the relationship to be managed dynamically by the renderer.

Refinements to maps

  • Map elements can use the <title> element in place of the title attribute.
  • Relationship table elements can have <title> as an optional first child.
  • Topicref elements can use the <navtitle> element in place of the navtitle attribute.
  • Maps and topicrefs can now contain the same metadata elements as topic prologs.
  • New topicref attribute named processing-role. Indicates whether or not a topic reference contributes to the navigation structure of the containing map.

Refinements to content references

  • Content references can now point to ranges of elements. For example, a single content reference from a <step> element can include a sequence of <step> elements.
  • Content references can "push" elements into a target context, allowing unilateral augmentation of topics from other topics. For example, given a base topic with generic content, a using map could include both the generic topic and a separate topic that uses conref push to add map-specific content to the generic topic.
  • Content reference resolution can be deferred so that it is done later in a rendering process or completely deferred so that it can be done by a separate delivery mechanism, for example., Eclipse information centers.

Refinements to topic elements

  • The base task topic type has a more relaxed content model. This enables creation of a wider variety of specialized tasks, including task specializations that do not have formal markup for individual steps. The OASIS-defined task shell document type integrates a constraint module that imposes the same constrained content model as defined in the DITA 1.1 task topic type.
  • A number of content elements allow the new @keyref attribute, including the <ph>, <keyword>, and <term> elements. When using the @keyref attribute, these elements can get their effective content from the key-defining <topicref> element and can also be treated as navigation links to the resource pointed to by the key-defining <topicref> element, if any. For example, a term element can use @keyref to link to the glossary entry topics for the term.
  • The <image> element takes the new @scalefit attribute, which indicates whether or not the image should be scaled to fit the presentation context.
  • The <draft-comment> element is now allowed in most contexts.
  • The <figgroup> element now allows <data> as a subelement.

Refinements to specialization

  • Structural and domain vocabulary modules can now both be listed in the domains attribute. Structural modules can depend on and specialize elements from domains. For example, a structural domain for reference topics for a specific programming language could depend on the Programming domain (pr-d) and specialize elements from that domain.
  • Information Architects can indicate whether the use of a given vocabulary module requires strict or weak checking of content reference constraints.
  • The implementation patterns for vocabulary modules have been refined. In particular, each element type now defines a separate parameter entity for its content model and attribute list, allowing per-element configuration of content models and attribute lists through constraint modules.

Other refinements

  • The <dita> element now has the @DITAArchVersion attribute.
  • A number of processing details have been clarified where they were underspecified in DITA 1.1.
  • Most attributes that had enumerated values in DITA 1.1 are now unenumerated, allowing specializations to define different enumerations if they choose.