B.4.2 Migrating from DITA 1.1 to 1.2
DITA 1.2 is compatible with prior versions of the DITA specification in that all valid DITA 1.0 and 1.1 documents are valid DITA 1.2 documents. However, some changes to existing document type shells and specializations might be needed in order to maintain the same behavior under DITA 1.2 or to take full advantage of new DITA 1.2 features.
Migration of task specializations
DITA 1.2 relaxes the content model for the
<taskbody> element in the base
type. Specializations of
<task> that use the
<taskbody> element unchanged or use the
content-model parameter entities for task body will use the more general DITA 1.2 task model
when used with the DITA 1.2 task module.
- Documents that use the task topic type included with the OASIS DITA 1.2 specification will not need to migrate. This includes documents that use task inside of the ditabase document type included with the DITA 1.2 specification.
- Documents that use the standard task module inside of a new document type shell, or in a local ditabase document type, will need to migrate in order to preserve the module.
- Documents that use a specialization of task with a specialized element to replace
<taskbody>will not need to migrate. Documents that specialize task but reuse the
<taskbody>element will need to migrate.
For documents that do not use the standard OASIS DITA doctypes for which the strict task model from DITA 1.0 and 1.1 is desired, the strict task model can be restored by using the strict Taskbody Constraint module, by creating and integrating a constraint module similar to the strict Taskbody Constraint, or by adjusting the specialization's content models to impose the appropriate constraints.
<!ENTITY % strictTaskbody-c-def PUBLIC "-//OASIS//ELEMENTS DITA 1.2 Strict Taskbody Constraint//EN" "strictTaskbodyConstraint.mod"> %strictTaskbody-c-def;
<xs:include>element should be placed immediately before the
<xs:include schemaLocation="urn:oasis:names:tc:dita:xsd:strictTaskbodyConstraintMod.xsd:1.2" />
<taskbody>model must also be migrated. In this case, the documents must be updated to reference the General Task document type instead of the traditional Task document type. For DTD-based documents, this means that the document type declaration must change as follows within each task document:
DITA 1.1: <!DOCTYPE task PUBLIC "-//OASIS//DTD DITA Task//EN" "task.dtd"> DITA 1.2: <!DOCTYPE task PUBLIC "-//OASIS//DTD DITA General Task//EN" "generalTask.dtd">
DITA 1.1: <task xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:oasis:names:tc:dita:xsd:task.xsd" DITA 1.2: <task xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:oasis:names:tc:dita:xsd:generalTask.xsd"
Use of glossary document type shell and module files
The files named glossary.dtd, glossary.mod, and glossary.ent in DITA 1.1 have been renamed to glossentry.dtd, glossentry.mod, and glossentry.ent in order to follow the file naming requirements for vocabulary modules. The XML Schema files glossary.xsd, glossaryGrp.xsd, and glossaryMod.xsd have been renamed to glossentry.xsd, glossentryGrp.xsd, and glossentryMod.xsd.The DITA 1.2 entity resolution catalogs map the public identifiers for the glossary.* files to the corresponding glossentry.* files and URNs for the glossary*.xsd files to the corresponding glossentry*.xsd files, meaning that existing documents and shell document types that refer to the glossary.* files will continue to work with DITA 1.2.
However, shell document types that refer to the glossary.* files should be updated to refer to the corresponding glossentry.* files as it is convenient to do so.
Migration of specializations to reflect new implementation patterns
DITA 1.2 defines new implementation patterns for specializations. It is not necessary to update existing specialization modules to reflect these new patterns. However, specializations that want to enable the use of constraint modules must be updated to provide per-element-type content model and attribute list parameter entities.
Existing specializations might benefit from the new DITA 1.2 ability to have structural modules that depend on and specialize elements from domains.
Update of domains attributes for specializations
In DITA 1.1 the
@domains attribute only listed the domains on which a given map or topic type
depended. In DITA 1.2 the
@domains attribute should also list structural modules and constraint
modules, providing a complete list of the vocabulary modules that a given map or topic type
depends on in the context of a given DITA document type.
Existing structural specializations should be updated to include the structural module names
in their domains attribute configuration entities. Having a complete declaration of all
structural and domains modules in the
@domains attribute allows processors to determine the set
of required modules for a given topic or map document without also examining all the
attributes of all the elements in the document.
XML Schema declaration of domains attribute
@domainsattribute is declared has changed. In DITA 1.1 the
@domainsattribute was defined using an
<xs:redefine>element. For DITA 1.2 the attribute is defined in document type shells and referenced from modules, like so:
<xs:attributeGroup name="domains-att"> <xs:attribute name="domains" type="xs:string" default="(topic ui-d) (topic hi-d) (topic sw-d) (topic pr-d) (topic ut-d) (topic indexing-d) (topic hazard-d) (topic abbrev-d)" /> </xs:attributeGroup>
XML Schema document type shells must be updated to use the new declaration mechanism in order to continue to be valid XSD schemas.