L'élément <data> représente des propriétés, depuis des valeurs simples jusqu'à des structures complexes. Les processus peuvent cueillir l'élément <data> en vue d'un traitement automatique ou du formatage des données associées au flux principal (body flow). L'élément <data> sert principalement à créer des spécialisations.
On peut imbriquer des éléments <data> pour des structures. On peut utiliser l'attribut name
pour indiquer la sémantique des instances de l'élément <data>, telles que des adresses, des dates, des quantités,
et ainsi de suite. Dans beaucoup de cas néanmoins, on peut choisir de spécialiser l'élément <data>
pour des sémantiques plus précises et pour des contraintes sur les structures et les valeurs. Par exemple, une spécialisation peut spécifier
une énumération de l'attribut value.
Dans certains cas, il n'est pas possible ni pratique de garder une propriété comme partie de son sujet. Par exemple, on préférera
garder des données complètes dans le prologue (<prolog>) qui s'applique à une note ou un exemple dans le corps.
Pour traiter ces exceptions, on peut utiliser l'élément <data-about> pour identifier le sujet de la propriété.
Un processus peut recueillir les valeurs de données (data values) en vue d'une
représentation automatique (machine-processable) telle que RDF.
Le formatage par défaut ignore l'élément <data> dans l'élément <body>.
Comprenant si et comment les propriétés devraient s'afficher, un traitement personnalisé ou spécialisé peut étendre le formatage
afin d'inclure les valeurs de données dans certaines sorties formatées.
Spécialiser l'élément <data> pour du texte qui fait partie du flux principal (body flow),
notamment pour échapper aux contraintes des modèles de contenu de base, est un abus de l'architecture DITA.
Par exemple, un type de paragraphe spécial doit spécialiser l'élément de base <p> plutôt que l'élément <data>.
Lors de l'échange du contenu avec d'autres ou au retrait d'une spécialisation, un paragraphe spécialisé de l'élément <data>
sera généralisé et de ce fait passé par le formatage de base, mutilant le flux du discours et donnant un contenu invalide.
Les utilisations de l'élément <data> comprennent :
data> pour définir l'adressage sur l'enveloppe du message.
Par exemple, un thème pourrait modéliser un courrier électronique en représentant l'adresse avec des éléments <data>
spécialisés dans l'élément <prolog> et le contenu avec l'élément <body> ;data> spécialisés incluant ceux de la
Spécification technique des composants élémentaires UN/CEFACT
(http://www.unece.org/cefact/).L'exemple suivant spécifie le code source délimité d'un fragment de code afin qu'un processus automatique puisse rafraîchir le
fragment de code. Les éléments <fragmentSource>, <sourceFile>, <startDelimiter> et <endDelimiter> sont
spécialisés de <data> mais l'élément <codeFragment> l'est de <codeblock>.
Ces propriétés n'apparaîtront pas dans la sortie formatée (sauf peut-être pour des problèmes de débogage dans le rafraîchissement) :
<example>
<title>An important coding technique</title>
<codeFragment>
<fragmentSource>
<sourceFile value="helloWorld.java"/>
<startDelimiter value="FRAGMENT_START_1"/>
<endDelimiter value="FRAGMENT_END_1"/>
</fragmentSource>
...
</codeFragment>
</example>
L'exemple suivant identifie une propriété immobilière comme faisant partie de la description d'une maison.
L'élément <realEstateProperty> et tout ce qu'il contient sont spécialisés de <data>.
L'élément <houseDescription> est spécialisé de l'élément <section>. Un processus spécialisé
peut formater les valeurs pour identifier le terrain si c'est approprié pour la brochure.
<houseDescription>
<title>A great home for sale</title>
<realEstateProperty>
<realEstateBlock value="B7"/>
<realEstateLot value="4003"/>
...
</realEstateProperty>
<p>This elegant....</p>
<object data="B7_4003_tour360Degrees.swf"/>
</houseDescription>
Section parente 5. Spécialisation DITA
5.4. Spécialisation d'un contenu étranger ou inconnu
5.6. Limites de la spécialisation
Retour au sommaire.
OASIS DITA Version 1.1 Architectural Specification — OASIS Standard, 1 August 2007
Copyright © OASIS Open 2005, 2007. All Rights Reserved.