Changes from DITA 1.1 to DITA 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 (indirect) 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 DITA learning and training content specialization.
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.