Jump to main content
  Darwin Information Typing Architecture (DITA) Version 1.3 Part 3: All-Inclusive Edition Plus Errata 02  OASIS Standard Incorporating OASIS Approved Errata of Errata 02  19 June 2018  DITA Version 1.3 Specification
Darwin Information Typing Architecture (DITA) Version 1.3 Part 3: All-Inclusive Edition Plus Errata 02 OASIS Standard Incorporating OASIS Approved Errata of Errata 02 19 June 2018 DITA Version 1.3 Specification
  • Introduction to DITA 1.3
  • Architectural specification: All-inclusive edition
  • Language reference: All-inclusive edition
  • Non-normative information
  • Content models for learning and training package
Index
  1. Home
  2. Language reference: All-inclusive edition

    The language reference portion of the DITA specification contains a topic for each DITA element. The topic defines the element, its inheritance hierarchy, and provides examples of usage. This portion of the DITA specification also includes information about DITA attributes.

  3. Technical content elements

    Elements in the technical content section include the original Concept, Task, and Reference specializations, as well as specializations added in later releases. It also includes domains designed primarily for technical content.

  4. Technical-content domains elements

    Domains in this section include those generally associated with technical content, such as the programming and software domains.

  5. Task requirements domain

    The task requirements domain contains elements for use in describing tasks that involve machines or other pieces of hardware.

  6. nospares

    The <nospares> element specifies that no spare parts are needed to perform a task.

  • Specification URIs
  • Notices
  • Introduction to DITA 1.3

    The Darwin Information Typing Architecture (DITA) specification defines a set of document types for authoring and organizing topic-oriented information, as well as a set of mechanisms for combining, extending, and constraining document types.

  • Architectural specification: All-inclusive edition

    The architectural specification portion of the DITA specification outlines the framework of DITA. It contains an overview of DITA markup; addressing; processing; configuration, specialization, generalization, and constraints; as well as information about coding DITA grammar files.

  • Language reference: All-inclusive edition

    The language reference portion of the DITA specification contains a topic for each DITA element. The topic defines the element, its inheritance hierarchy, and provides examples of usage. This portion of the DITA specification also includes information about DITA attributes.

    • Element quick reference

      This section contains a listing of DITA elements.

    • Topic elements

      The base topic elements include elements that make up the core building blocks of the DITA topic, such as topic, body, and related-links, as well as elements like <p> and <ph> that are used in many topic specializations. Some of these elements are also available inside the <topicmeta> map element.

    • Map elements

      Map elements include the core components of DITA maps, such as <topicref> and <reltable>, as well as general purpose map specializations in the map group domain.

    • Metadata elements

      Metadata elements include information that is located within the <topicmeta> element (in maps) or <prolog> element (in topics), as well as indexing elements that can be placed in additional locations within topic content.

    • Domain elements

      General purpose domains are not specific to any type of information, such as the hazard statement domain that provides elements for describing hazardous situations.

    • Classification elements

      Classification elements support managing metadata. Those in the subject scheme map are used to define controlled values and to bind the controlled values to DITA attributes as enumerations. Those declared in the classification domain are used in other maps to classify content according to the scheme.

    • Specialization elements

      Several DITA elements exist either for architectural reasons or for support of specialized markup yet to be designed. Although there is little need to use these elements unless you are directed to, some of them, such as <state>, can be used if your content makes use of these semantic distinctions. For example, a discussion of signals on a gate of an integrated logic circuit might use the <state> element to represent either on or off conditions of that gate.

    • Legacy conversion elements

      Conversion elements exist primarily to aid in the conversion of content to DITA.

    • DITAVAL elements

      A conditional processing profile (DITAVAL file) is used to identify which values are to be used for conditional processing during a particular output, build, or some other purpose. The profile should have an extension of .ditaval.

    • Technical content elements

      Elements in the technical content section include the original Concept, Task, and Reference specializations, as well as specializations added in later releases. It also includes domains designed primarily for technical content.

      • Concept elements

        DITA concept topics answer "What is..." questions. Use the concept topic to introduce the background or overview information for tasks or reference topics. The concept topic restricts content following a section or example to other sections or examples. For more details on when to use concept and other information types, please refer to the DITA architectural specification.

      • Task elements

        Task topics answer "How do I?" questions, and have a well-defined structure that describes how to complete a procedure to accomplish a specific goal. Use the task topic to describe the steps of a particular task, or to provide an overview of a higher-level task. The task topic includes sections for describing the context, prerequisites, actual steps, expected results, example, and expected next steps for a task. For more details on when to use task and other information types, please refer to the DITA architectural specification.

      • Reference elements

        Reference topics describe factual material about a subject, such as the commands in a programming language. This format is also suitable for bibliographies, catalogues, the list of ingredients for recipes, and similar collections of structured descriptive prose. For more details on when to use reference and other information types, please refer to the DITA architectural specification.

      • Troubleshooting elements

        Troubleshooting topics document corrective action such as troubleshooting or alarm clearing.

      • Glossary elements

        Glossary elements include those elements designed to specify terms and their definitions, as well as elements that are designed to group, reference, or otherwise make use of information in the glossentry topic.

      • Bookmap elements

        Elements in the bookmap section are used to organize DITA content into book form. They include elements for dividing up content, such as chapter and appendix, as well as metadata specific to publishing.

      • Technical-content domains elements

        Domains in this section include those generally associated with technical content, such as the programming and software domains.

        • Equation domain elements

          The elements in the equation domain enable authors to clearly distinguish equations from other type of content. These markup distinctions can enable formatting distinctions, numbering of equations, and more. This domain can be used independently of the MathML domain.

        • Markup domain

          The markup domain elements are used for the mention of named constructs in markup languages, such as XML.

        • MathML domain elements

          The MathML domain elements enable direct use of MathML markup within DITA documents, as well as use-by-reference of MathML markup that is stored separate, non-DITA documents. MathML is a W3C standard.

        • Programming elements

          The programming domain elements are used to define the syntax for programming languages. They also can be used to provide examples.

        • Release-management domain elements

          The release-management domain elements contain human-authored information about the changes that have been made to a DITA topic or map. A processor can retrieve this information and use it to assemble documents or topics that contain release note information.

        • Software elements

          The software domain elements are used to describe the operation of a software program.

        • SVG elements

          The SVG domain elements enable direct use of SVG markup within DITA documents, as well as use-by-reference of SVG markup that is stored in separate non-DITA documents. SVG is a W3C standard.

        • Task requirements domain

          The task requirements domain contains elements for use in describing tasks that involve machines or other pieces of hardware.

          • prelreqs

            The <prelreqs> element contains information about preliminary requirements – the things the user needs to know or do before starting a task. This element contains information about personnel requirements, safety conditions, support equipment, supplies, and spare parts.

          • closereqs

            The <closereqs> element contains information about closing requirements – steps or tasks that the user should perform after completing a task, for example, "Check around the vehicle for any drips or leaks."

          • reqconds

            The <reqconds> element contains information about conditions that must be fulfilled before performing a task.

          • reqcond

            The <reqcond> element specifies a condition that must be fulfilled before performing a task, for example, "Rear Oil Seal replacement."

          • noconds

            The <noconds> element specifies that there are no conditions to be fulfilled before performing a task.

          • reqcontp

            The <reqcontp> element specifies a technical publication that can be used to fulfill a condition before performing a task. It might also specify a publication that is required in order to fulfill the condition, such as a list of local regulations.

          • reqpers

            The <reqpers> element contains information about the personnel who are required to perform a task. This information might specify the number of workers, the type and skill level of the workers, and the length of time that they will need to perform the task.

          • personnel

            The <personnel> element specifies the minimum number of workers who are required to perform a task.

          • perscat

            The <perscat> element specifies the type or category of workers that is required by a task.

          • perskill

            The <perskill> element specifies the skill level of the workers who perform the task.

          • esttime

            The <esttime> element provides an estimate of the time that is required to perform a task.

          • supeqli

            The <supeqli> element contains a list of the tools, support equipment, or monitoring equipment that is required to perform a task. These pieces of support equipment need to be assembled prior to beginning the task.

          • supequi

            The <supequi> element specifies a tool, a piece of support equipment, or a piece of monitoring equipment that is needed to perform a task, such as a slide hammer.

          • supequip

            The <supequip> element contains information about the support equipment that is required to perform a task. This element either contains children elements that specify particular items of support equipment or a <nosupeq> element that specifies that no support equipment is required.

          • nosupeq

            The <nosupeq> element indicates that there is no support equipment required to perform a task.

          • supplies

            The <supplies> element contains information about the supplies or parts that are required to perform a task. These supplies or parts need to be available prior to beginning the task. This element either contains children elements that specify particular supplies or a <nosupply> element that indicates that no supplies are needed.

          • supply

            The <supply> element contains information about a single supply in a list of supplies that are needed to perform a task.

          • supplyli

            The <supplyli> element specifies a list of supplies needed to perform a task.

          • nosupply

            The <nosupply> element specifies that no supplies are needed to perform a task.

          • spare

            The <spare> element specifies a particular spare part that is required to perform a task, for example, a "dipstick."

          • spares

            The <spares> element contains information about the spare parts that are needed for a task. This information might specify particular spare parts or it might state that no spare parts are required.

          • sparesli

            The <sparesli> element contains information about the spare parts that are required to perform a task.

          • nospares

            The <nospares> element specifies that no spare parts are needed to perform a task.

          • nosafety

            The <nosafety> element specifies that there are no safety conditions to be considered.

          • safecond

            The <safecond> element specifies a safety condition that must be considered prior to completing a task. It might also contain a complete hazard statement.

          • safety

            The <safety> element contains information about safety conditions. This element either contains children elements that describe safety conditions or a <nosafety> element that indicates that there are no safety conditions that must be considered.

        • User interface elements

          The user interface domain elements are used to describe the user interface of a software program.

        • XML mention domain

          Use the XML-mention domain elements for mentions of named XML constructs, including elements, attributes, entities, processing instructions, and document-type declaration components. These elements enable specific typographic effects for different construct types, precise search and retrieval of specific constructs, and automatic indexing of different constructs. This domain is intended to support the description and documentation of XML document types and XML applications.

        • xNAL domain elements

          The xNAL domain elements represent a subset of the Extensible Name and Address Standard. It is used to encode information about the author or authors of DITA information. The domain can be included in any DITA document type shell that requires additional metadata for names and addresses, although the implementations provided by OASIS only include it in the bookmap document type.

    • Learning and training elements

      Elements in the learning and training section include specialized topics, maps, content, and metadata elements specially designed to support instructional content.

    • Attributes

      This section collects commonly used attributes, with common definitions. If an element uses a different definition, or narrows the scope of, an otherwise common attribute, it will be called out in the topic that defines the element.

  • Conformance

    Conformance to the DITA specification allows documents and document types that are used with different processors or different versions of a processor to produce the same or similar results with little or no reimplementation or modification.

  • Acknowledgments

    (Non-normative) Many members of the OASIS DITA Technical Committee participated in the creation of this specification and are gratefully acknowledged.

  • Non-normative information

    This section contains non-normative information, including topics about new features in DITA 1.3 and migrating from DITA 1.2 to DITA 1.3.

  • Content models for learning and training package

    For each element in the learning and training package, this section presents the content model and a list of parent elements that can contain that element.

<nospares>

The <nospares> element specifies that no spare parts are needed to perform a task.

Content models

See appendix for information about this element in OASIS document type shells.

Inheritance

+ topic/data task/data taskreq-d/nospares

Example

<spares>
	<nospares/>
</spares>

Attributes

The following attributes are available on this element: Data element attributes group, Link relationship attribute group, Universal attribute group, @keyref, and outputclass.

On this page
  • Content models
  • Inheritance
  • Example
  • Attributes
Generated by <oXygen/> XML WebHelp