Language reference : Base architecture : Specialization elements : data
The <data> element represents a property within a DITA topic or map. While the <data> element can be used directly to capture properties, it is particularly useful as a basis for specialization. Default processing should treat the content as an unknown kind of metadata and ignore it for rendering, but custom processing may match the name attribute or specialized element and use the element for automated manipulation or to format data associated with the body flow. For example, a specialized data element may be used to format properties as sidebars or other adornments or to harvest properties for automated processing.
The subject of the property is ordinarily the container of the <data> element. In the content model for the <prolog> and <metadata> elements, the property applies to the topic as a whole. In the <topicmeta> element, the property applies to the referenced topic. The <data-about> element may be used to identify the subject of the property with an explicit reference.
The name attribute names the property for processes. A <title> subelement may provide a label for the property. The datatype attribute may be used to identify the type for the value. The value of the property can be any of the following:
A simple text value expressed with the value attribute or textual content.
A reference to either DITA content or a non-DITA resource expressed with the href attribute.
An image or other non-textual object.
A brief unit of descriptive text that is not part of the body text flow.
A complex structure composed of nested <data> elements.
Processors should ignore the content of the <data> element by default, so the <data> element should only be used for properties and not to embed text for formatting as part of the flow of the topic body. It might be tempting to specialize the <data> element for text that is part of the body flow, so as to escape the constraints of the base content models. This abuse of the DITA architecture will cause problems. For example, if a particular kind of paragraph is specialized from <data> rather than from <p>, then when the content is exchanged with others that do not recognize the specialized element, their processors will skip the content.
The <data> element may be nested to create structures for complex properties. The name attribute may be to distinguish different semantics associated with different instances of the <data> element such as addresses, times, amounts, and so on. In many cases, however, it is preferable to specialize the <data> element for more precise semantics and for constraints on structures and values. For instance, a specialization can specify an enumeration for the value attribute.
A <data> element containing properties of a topic as a whole should be located in the topic's <prolog> or <metadata> element, or in a <topicmeta> element related to a <topicref> that references the topic. The <data> element generally goes at the beginning of the element to which the properties in it refer. Where this is unwieldy, the <data> element can go in the <prolog>, with the data-about attribute identifying which specific element in the topic is the reference.
Note: These models represent only the default document types distributed by OASIS. Actual content models will differ with each new document type.
Content model
topic (base), map (base), classifyMap, subjectScheme, learningAssessment, learningBookmap, learningContent, learningMap, learningOverview, learningPlan, learningSummary
( text data or data or data-about or foreign or unknown or keyword or term or image or object or ph or b or i or sup or sub or tt or u or title) (any number)
topic (technical content), map (technical content), concept, ditabase, glossary, glossentry, glossgroup, reference, task, bookmap
( text data or data or data-about or foreign or unknown or keyword or apiname or option or parmname or cmdname or msgnum or varname or wintitle or term or abbreviated-form or image or object or ph or b or i or sup or sub or tt or u or codeph or synph or filepath or msgph or systemoutput or userinput or menucascade or uicontrol or title) (any number)
( text data or data or data-about or foreign or unknown or keyword or wintitle or term or image or object or ph or b or i or sup or sub or tt or u or menucascade or uicontrol or title) (any number)
Contained by
Content model
topic (base)
map (base)
topic (technical content)
map (technical content)
glossary, glossentry, glossgroup
task (strict), task (general)
learningAssessment, learningOverview, learningSummary
data-about, data-about, data, title, navtitle, shortdesc, desc, p, note, lq, q, sli, li, itemgroup, dthd, ddhd, dt, dd, fig, figgroup, pre, lines, ph, alt, stentry, draft-comment, fn, indexterm, index-base, cite, xref, entry, author, source, publisher, copyrholder, category, metadata, prodname, brand, series, platform, prognum, featnum, component, searchtitle, abstract, body, bodydiv, section, sectiondiv, example, prolog, linktext, linkinfo, lcIntro, lcObjectivesStem, lcObjective, lcAudience, lcTime, lcPrereqs, lcSummary, lcNextSteps, lcReview, lcResources, lcChallenge, lcInstruction, lcClient, lcPlanTitle, lcCIN, lcModDate, lcDelivDate, lcPlanSubject, lcPlanDescrip, lcPlanPrereqs, lcGeneralDescription, lcGoals, lcNeeds, lcValues, lcOrgConstraints, lcEdLevel, lcAge, lcBackground, lcSkills, lcKnowledge, lcMotivation, lcSpecChars, lcWorkEnvDescription, lcPlanResources, lcProcesses, lcTaskItem, lcAttitude, lcPlanObjective, lcJtaItem, lcGapItemDelta, lcLearnStrat, lcAssessment, lcDelivery, lcLMS, lcNoLMS, lcHandouts, lcClassroom, lcOJT, lcConstraints, lcW3C, lcPlayers, lcGraphics, lcViewers, lcResolution, lcFileSizeLimitations, lcDownloadTime, lcSecurity, b, u, i, tt, sup, sub, coords, index-see, index-see-also, index-sort-as, lcInteractionBase, lcQuestionBase, lcInstructornote, lcTrueFalse, lcSingleSelect, lcMultipleSelect, lcSequencing, lcMatching, lcHotspot, lcOpenQuestion, lcQuestion, lcOpenAnswer, lcFeedback, lcFeedbackCorrect, lcFeedbackIncorrect, lcAnswerContent, lcItem, lcMatchingItem, lcAreaCoords, lcLom
- topic/data
Example 186. Example
Uses of the <data> element may include the following:
Complex metadata properties such as bibliographic records corresponding to citations.
Hybrid documents with data values as part of the content, such as word processor formats using form fields.
Messages in which the payload includes human-readable content. Such applications can use the <data> element to define the addressing on the message envelope. For instance, a topic could model an email message by representing the address with specialized <data> elements in the <prolog> element and the content with the <body> element.
Transactional documents in which the values are processed but also displayed with human-readable content. In particular, a library of building blocks for transaction documents can be implemented through a DITA domain as specialized <data> elements including those from the UN/CEFACT Core Components Technical Specification (
Figure 60. Using the name attribute on unspecialized data elements
This structure identifies the library and version demonstrated by a code sample. The name attribute is used to identify both the grouping data element and the nested data elements that provide specific properties. These properties will not appear in the output unless a processor is customized to recognize these name attribute values.
<data name="exampleOf">
<data name="library" href="ajaxLibrary.js"/>
<data name="version" value="2006-6-19"/>
Figure 61. Specializing data to annotate a code sample
The following example specifies the delimited source code for a code fragment so an automated process can refresh the code fragment. The <fragmentSource>, <sourceFile>, <startDelimiter>, and <endDelimiter> elements are specialized from <data> but the <codeFragment> is specialized from <codeblock>. These properties wouldn't appear in the formatted output (except perhaps for debugging problems in the refresh):
<title>An important coding technique</title>
<sourceFile value=""/>
<startDelimiter value="FRAGMENT_START_1"/>
<endDelimiter value="FRAGMENT_END_1"/>
Figure 62. Specializing data to annotate housing information
The following example identifies a real estate property as part of a house description. The <realEstateProperty> element and its child elements are specialized from <data>. The <houseDescription> element is specialized from <section>. A specialized process can format the values as part of a brochure if they meet criteria for inclusion.
<title>A great home for sale</title>
<realEstateBlock value="B7"/>
<realEstateLot value="4003"/>
<p>This elegant....</p>
<object data="B7_4003_tour360Degrees.swf"/>
Data Type
Default Value
Defines a unique name for the object.
Describes the type of data contained in the value attribute or within the data element. A typical use of datatype will be the identifying URI for an XML Schema datatype.
Specifies a value associated with the current property or element.
Provides a reference to a resource. See The href attribute for detailed information on supported values and processing implications.
The format attribute identifies the format of the resource being referenced. See The format attribute for details on supported values.
Describes the target of a reference. See The type attribute for detailed information on supported values and processing implications.
The scope attribute identifies the closeness of the relationship between the current document and the target resource. See The scope attribute for more information on values.
(local | peer | external | -dita-use-​conref-​target)
univ-atts attribute group (includes select-atts, id-atts, and localization-atts groups)
A set of related attributes, described in univ-atts attribute group
global-atts attribute group (xtrf, xtrc)
A set of related attributes, described in global-atts attribute group
class, outputclass
Common attributes described in Other common DITA attributes