This architecture supports the proper construction of specialized DTDs from any higher-level DTD or schema. The base DTD is ditabase DTD, which contains an archetype topic structure and three additional peer topics that are typed specializations from the basic topic: concept, task, and reftopic. The principles of specialization and inheritance resemble the principle of variation in species proposed by Charles Darwin. So the name reminds us of the key extensibility mechanism inherent in the architecture.
Many good articles have been published about DITA covering such topics as experience reports, best practices, project planning, among others.
It's important to recognize that DocBook and DITA take fundamentally different approaches.
DocBook was originally designed for a single, continuous technical narrative (where the narrative might be of article, book, or multi-volume length). Through transforms, DocBook can chunk this technical narrative into topics to provide support for Web sites and other information sets. Because the goal of the DocBook DTD is to handle all standard requirements for technical documentation, the usage model encourages customization to exclude elements that aren't local requirements. The usage model supports but discourages local extensions because of the potential for unknown new elements to break tool support and interoperability.
By contrast, DITA was designed for discrete technical topics. DITA collects topics into information sets, potentially using filtering criteria. The core DITA information types are not intended to cover all requirements but, instead, provide a base for meeting new requirements through extension. Extension is encouraged, but new elements must be recognizable as specializations of existing elements. Through generalization, DITA provides for tool reuse and interoperability.
Each approach has its strengths. DocBook would be the likely choice for a technical narrative. DITA would be the likely choice for large, complex collections of topics or for applications that require both extensibility and interoperability. Technical communications groups might want to experiment with both packages to determine which approach is better suited for their processes and outputs.
The Darwin Information Typing Architecture was first introduced publicly by IBM in April 2001, and maintained through fixes and design updates through March 2004. IBM has contributed the design at the 1.1.3 level to OASIS (http://www.oasis-open.org) as a Technical Committee activity. The DITA TC will take over maintenance and formal specification of the architecture.
These forums exist for discussion about DITA:The basic concepts of DITA are not tied to implementation. Both schemas and DTDs can be used to define specializable DITA elements. The current DITA Open Toolkit provides both DTDs and XML Schemas.
Because DITA is an architecture, not just a DTD, you have to ask the question in terms of which infotype (concept, task, reference) you have in mind, and containing which domains. New specializations always increase the count because they introduce delta (or new) elements, but the new content models typically have more restricted content models (which sometimes helps limit the selection choices that writers might see in a validating XML editor}.
Note: The following count is based on the developerWorks-based dita13 toolkit, which predates the OASIS DITA 1.0 Standard.
The unspecialized topic.dtd in DITA has 94 elements.
The 4 basic domains (software, programming, highlighting, UI) contribute 49 elements altogether, which brings the count for domain-specialized topic dtd to 143.
Since domain specialization inherits across all dtds derived from topic.dtd, 143 is the base count affecting the rest of the per-dtd totals that follow:
The delta elements added by any new specializations will affect the tag count in similar ways.
Because DITA is an architecture, not just a DTD, you have to ask the question in terms of which infotype (concept, task, reference) , containing which domains. New specializations always increase the count, but the new content models typically have more restricted content models, which limits the selection choices that writers actually see in a validating XML editor.
The following count is based on the developerWorks-based dita13 toolkit, which predates the OASIS DITA 1.0 Standard.
The unspecialized topic dtd in DITA has 94 elements.
The 4 basic domains (software, programming, highlighting, UI) contribute 49 elements, which brings the count for domain-specialized topic dtd to 143 elements. Since these domains are also added to each of the dtds derived from topic, this is the base count affecting the rest of the per-dtd totals.
Concept.dtd adds 2 elements for its single-dtd total of 145 elements.
Task.dtd adds 25 elements for its single-dtd total of 168 elements.
Reference.dtd add 12 elements for its single-dtd total of 155 elements.
Ditabase.dtd adds 1 element but includes the sum of new elements in all the infotypes, having a grand total of 183 elements.