SELFHTML/Aides à la navigation XML/DTD Définitions de type de document (DTD)| SELFHTML/Aides à la navigation XML/DTD Définitions de type de document (DTD) |
Quand vous notez en HTML quelque chose comme <p align="center"> un peu de texte</p>, alors <p> est l'élément, et align est un attribut qui peut être dans l'élément <p>. Vous pouvez déterminer les attributs dans vos propres DTD XML pour les 
types d'élément qui y sont définis. Lors de la définition d'un attribut, vous mentionnez quelles attributions de valeurs doivent être possibles.
Lors de la création de DTD, vous devez réfléchir s'il est judicieux de sauvegarder des données dans les attributs ou non. Pour beaucoup de propriétés il est assurément plus indiqué de définir ses propres types d'élément. Ainsi "couleur_cheveux" est par exemple une propriété naturelle typique d'une personne. Quand maintenant, dans la structure de données concernant la description d'une personne rien d'autre que la couleur des cheveux ne doit être pris en considération, alors la définition d'un type d'élément comme <couleur_cheveux>...</couleur_cheveux> suffit. Quand par contre, d'autres propriétés des cheveux doivent être prises en considération, par exemple la longueur, alors l'opportunité est donnée de définir la structure de données de telle façon qu'il y ait un élément avec différents attributs par exemple <cheveux couleur="..." longueur="...">...</cheveux>.
On est pourtant ainsi confronté à la situation où les données proprement dites de l'application sont placées dans les attributs de telle façon qu'aucune donnée en caractères sensée n'est plus possible entre le repère d'ouverture et le repère de fermeture de l'élément. On peut en effet se demander ce qui pourrait bien être placé entre le repère d'ouverture <cheveux couleur="..." longueur="..."> et le repère de fermeture </cheveux>. C'est pourquoi il est indiqué de ne placer dans les attributs que les données qui ne servent qu'au traitement de données proprement-dit. Si par contre il s'agit de données qui contiennent un contenu qui par exemple doit être affiché à l'écran, alors il vaut mieux définir pour elles des éléments distincts. Ainsi on pourrait aussi représenter la structure de données <cheveux couleur="..." longueur="...">...</cheveux> par exemple de la façon suivante:
<cheveux>
<couleur_cheveux>...</couleur_cheveux>
<longueur_cheveux>...</longueur_cheveux>
</cheveux>
 
|
Les attributs dans une DTD sont notés d'après le schéma suivant:
<!ELEMENT nom_element (contenu)> <!ATTLIST nom_element nom_attribut_1 contenu [#REQUIRED|#IMPLIED|#FIXED "valeur"|valeur_par_defaut] nom_attribut_n contenu [#REQUIRED|#IMPLIED|#FIXED "valeur"|valeur_par_defaut] > |
Les attributs sont définis par rapport aux types d'élément, c'est à dire que vous ne pouvez définir des attributs que pour des types d'élément définis.
La définition d'un attribut commence par une parenthèse pointue d'ouverture < suivie immédiatement à la suite d'un point d'exclamation ! et derrière, en majuscules, du mot clé ATTLIST. Le mot indique déjà que vous pouvez définir toute une liste d'attributs. Un type d'élément peut avoir autant d'attributs que l'on veut. Notez dans la liste d'attributs d'un type d'élément tous les attributs que vous voulez affecter à ce type d'élément. Derrière ATTLIST suit le nom du type d'élément auquel les attributs se réfèrent. Ce type d'élément doit être défini dans la DTD (voir éléments et règles d'imbrication).
Dans la liste d'attributs il est pratique de noter chaque définition d'attribut sur une ligne distincte. Chaque définition d'attribut de la liste d'attributs commence avec le nom de l'attribut. Vous pouvez choisir librement un nom. Il doit pourtant satisfaire aux règles pour les noms . Derrière le nom, notez des mentions sur le contenu du type d'attribut. Ces mentions peuvent être variées et règlent quelles valeurs un attribut peut avoir. Enfin chaque attribut doit encore recevoir l'un des mots clés #REQUIRED, #IMPLIED ou bien #FIXED avec une valeur mentionnée ou une valeur par défaut (plus de détails à ce sujet dans la partie sur les attributs obligatoires et facultatifs).
La définition de la liste d'attributs est clôturée par une parenthèse pointue de fermeture >. Les différentes parties de chaque définition sont séparées les unes des autres par un ou plusieurs espaces.
|
|
Attributs obligatoires et facultatifsVous devez toujours mentionner pour les attributs que vous définissez pour un type d'élément dans une DTD, si l'attribut doit être placé ou peut être placé dans l'élément. En HTML par exemple l'attribut src dans l'élément <img> est absolument obligatoire. L'attribut hspace peut être placé de la même manière dans cet élément mais ne le doit pas.
<!ELEMENT ressources (ressource)*> <!ELEMENT ressource (#PCDATA)> <!ATTLIST ressource url CDATA #REQUIRED langue CDATA #IMPLIED date_saisie CDATA #REQUIRED date_modification CDATA #IMPLIED > |
L'exemple définit comme contenu pour le type d'élément ressources un type d'élément nommé ressource. Pour ce type d'éléments sont définis quatre attributs. Deux de ces quatre attributs à savoir ceux avec les noms url et date_saisie doivent être notés lors de l'utilisation du type d'élément. Les deux autres, langue et date_modification, peuvent être notés. Marquez les attributs obligatoires par le identificateur-clé #REQUIRED, et les attributs facultatifs par #IMPLIED. Les deux mentions doivent chacune figurer en fin d'une définition d'attribut.
Il est stipulé pour les quatre attributs de l'exemple que la valeur affectée comporte des données en caractères. Ceci est indiqué par le mot clé CDATA (voir Attributs de type chaîne).
Exemple d'affichage: aperçu (un navigateur XML affiche par exemple la structure de données)
<?xml version="1.0" encoding="ISO-8859-1" ?> <!DOCTYPE ressources SYSTEM "ressources.dtd"> <ressources> <ressource url="http://alpentouren.teamone.de/"langue="de" date_saisie="09.11.2000" > Description hypertextuelle préparée pour quantité d'excursions à vélo par les cols des Alpes </ressource> <ressource url="http://www.planetbike.co.nz/" date_saisie="10.12.2000" date_modification="16.12.2000" langue="en"> Ballades en VTT à travers la Nouvelle Zélande </ressource> </ressources> |
Dans l'exemple deux éléments du type ressource sont notés. Pour le premier élément, les deux éléments obligatoires url et date_saisie sont notés ainsi que l'élément facultatif langue, dans le deuxième élément par contre les quatre attributs définis sont notés.
|
|
Attributs de type chaîneChaque attribut en XML doit recevoir une affectation de valeur. Dans de nombreux cas, la valeur affectée ne se limite pas à une certaine plage de valeurs mais peut avoir un nombre indéterminé de valeurs possibles. C'est le cas par exemple quand l'attribut contient une courte description, une valeur numérique une valeur en pourcentage ou une mention de mesure. Ces attributs sont nommés attributs de type chaîne.
<!ELEMENT autos (auto)*> <!ELEMENT auto EMPTY> <!ATTLIST auto type CDATA #REQUIRED annee_construction CDATA #REQUIRED km CDATA #REQUIRED puissance CDATA #REQUIRED prix_vente CDATA #REQUIRED > |
Dans l'exemple un élément vide sans contenu nommé auto a été défini. Cinq attributs obligatoires ont été affectés à ce type d'élément. Tous contiennent une valeur en caractères. Pour ce genre de valeur vous devez mentionner derrière le nom d'attribut comme contenu d'attribut l'identificateur-clé #CDATA. Une valeur en caractères est une chaîne de caractères de votre choix, d'une longueur choisie donc du texte, des chiffres et des caractères spéciaux. #CDATA est une abréviation pour character data, en français données en caractères ).
Exemple d'affichage: aperçu (un navigateur XML affiche par exemple la structure de données)
<?xml version="1.0" encoding="ISO-8859-1" ?> <!DOCTYPE autos SYSTEM "autos.dtd"> <autos> <auto typ="AUDI 80" annee_construction="1992" km="125000" puissance="90" prix_vente="6250 Euros" /> </autos> |
Tous les attributs définis dans l'exemple d'application ont été affectés à l'élément auto. Peu importe qu'il s'agisse de chaînes de caractères, de nombres ou des deux, toutes les affectations de valeurs en XML se classent dans ce qui est recouvert par CDATA en XML.
Peu importe ce qui figure comme affectation de valeur dans les attributs pour CDATA. Pour n'autoriser que certaines affectations de valeur vous pouvez définir des attributs avec des valeurs au choix invariables.
Dans les affectations de valeur à des attributs, vous pouvez aussi utiliser l'apostrophe ' et le guillemet ". Vous devez alors absolument toutefois masquer ces deux signes, à savoir sous la forme ' pour ' et " pour ".
|
|
Attributs avec des valeurs au choix invariablesVous connaissez sans soute de nombreux éléments de HTML qui n'autorisent que certaines valeurs. Ainsi l'attribut align ne permet, dans les éléments où il peut être placé que les valeurs telles que left, center, right et justify. Vous pouvez également définir en XML ces éléments avec certaines affectations de valeur autorisées.
<!ELEMENT hotels (hotel)*> <!ELEMENT hotel (#PCDATA)> <!ATTLIST hotel nom CDATA #REQUIRED categorie (I|II|III|IV|V) #REQUIRED chambre_simple (oui|non) #IMPLIED chambre_double (oui|non) "oui" > |
Dans l'exemple, un type d'élément hotel est défini. Quatre attributs ont été attribués à ce type d'élément. Le premier est un attribut obligatoire avec une valeur de type chaîne. Les trois autres n'ont pas une valeur chaîne nais attendent une des affectations de valeurs possibles déterminées. Les valeurs possibles sont notées entre parenthèses, séparées les uns des autres par le "ou" logique, symbolisé par la barre verticale |. L'attribut categorie permet de cette façon un des valeurs possibles I, II, III, IV ou V. Les attributs chambre_simple et chambre_double permettent les affectations de valeur oui ou bien non. De plus, il est possible pour les attributs avec des valeurs au choix invariables de définir une de ces valeurs comme valeur par défaut. C'est le cas dans l'exemple pour l'attribut chambre_double. Là, derrière la parenthèse incluant les affectations de valeur possibles, et séparée par un ou plusieurs espaces, est notée entre guillemets une des valeur comme valeur par défaut - dans l'exemple, il s'agit de la valeur oui. Quand vous notez une telle valeur par défaut, il n'est plus possible de mentionner par la suite si l'attribut est indispensable (#REQUIRED) ou facultatif (#IMPLIED). Car la valeur par défaut fait en sorte que l'attribut est interprété en interne comme étant indispensable par l' analyseur syntaxique. Quant l'attribut est omis dans l'application, la valeur par défaut sera prise automatiquement.
Exemple d'affichage: aperçu (un navigateur XML affiche par exemple la structure de données)
<?xml version="1.0" encoding="ISO-8859-1" ?> <!DOCTYPE hotels SYSTEM "hotels.dtd"> <hotels> <hotel nom="Au lion d'or" categorie="IV"> hôtel situé en lisière de forêt, 150 lits, calme et cher. </hotel> <hotel nom="Arabesque" categorie="II" chambre_double="oui" chambre_simple="oui"> hôtel en ville simple, 400 chambres, satisfaisant, sans confort particulier. </hotel> <hotel nom="Lancelot" categorie="III" chambre_simple="non"> hôtel situé dans le centre, 100 lits, agréable, facilement accessible. </hotel> </hotels> |
L'exemple montre trois applications autorisées de l'élément hotel. Dans le premier cas, seuls sont notés les deux attributs qui ont été définis comme indispensables dans la DTD. Pour l'attribut chambre_double la valeur par défaut oui a été interprétée en interne.
Dans la deuxième application l'attribut chambre_double a été noté explicitement, et la valeur par défaut lui a été affectée. À vrai dire, cette mention est superflue, car elle fait double emploi avec l'interprétation. La notation correspond à peu près à la mention en HTML align="left" où l'affectation de valeur left est définie comme valeur par défaut.
L'attribut chambre_simple, qui est défini comme étant facultatif (#IMPLIED), ne reçoit aucune valeur dans les deux premières applications de l'exemple. Dans la troisième, la valeur non lui est attribuée explicitement.
Les affectations de valeur à des attributs avec des valeurs au choix invariables ne doivent contenir aucun espace, donc en fin de compte ne pas comporter plus d'un mot.
La possibilité existe aussi d'imposer une certaine affectation de valeur pour un attribut. Pour cela notez (exemple):
type (hotel | motel) #FIXED "hotel"
Par la mention #FIXED vous obtenez qu'aucune autre affectation de valeur que hotel ne soit possible pour l'attribut type, bien qu'une autre possibilité soit définie. Ces constructions peuvent être appropriées quand un attribut doit pouvoir se voir attribuer d'autres valeurs par la suite mais doit déjà être "établi".
|
|
Outre les attributs avec des données en caractères au choix (CDATA) comme valeur ou avec des valeurs au choix invariables il y a des attributs qui attendent comme affectation de valeur une valeur d'identificateur. Les valeurs d'identificateur sont des valeurs qui identifient telles des noms ou des numéros. Font partie de ce groupe:
Attributs avec une valeur d'identification
Attributs avec une valeur d'identification de référence
Attributs avec une valeur d'entité (par exemple pour des références de fichier externe)
Attributs avec une valeur nmtoken (même pour les identifications numériques)
|
|
Attributs avec une valeur d'identificationXML prévoit la possibilité de signaler à l' analyseur syntaxique que la valeur affectée d'un certain attribut ne peut être placée qu'une fois dans tout le document. Ceci est une propriété importante avant tout par rapport aux langages script. Car ce n'est que par des valeurs claires d'identification pour tout le document qu'il est possible d'adresser un élément par sa valeur d'identification.
<!ELEMENT livres (livre)*> <!ELEMENT livre (#PCDATA)> <!ATTLIST livre isbn ID #REQUIRED titre CDATA #REQUIRED auteur CDATA #REQUIRED > |
Dans l'exemple, un type d'élément livre a été défini auquel trois Attributs obligatoires ont été affectés. Deux d'entres eux contiennent des valeurs en caractères, le troisième une valeur d'identification - à savoir l'attribut isbn. Pour définir un attribut avec une valeur d'identification, notez pour la désignation l'identificateur-clé ID à la place de CDATA.
Exemple d'affichage: aperçu (un navigateur XML affiche par exemple la structure de données)
<?xml version="1.0" encoding="ISO-8859-1" ?> <!DOCTYPE livres SYSTEM "livres.dtd"> <livres> <livre isbn="nr_3-90193-3949-7" titre="Fleurette facile" auteur="Professeur Trouvetout"> Une introduction entre le génie et la folie. </livre> <livre isbn="nr_3-90193-3950-2" titre="Fleurette facile II" auteur="Professeur Trouvetout"> Une autre introduction entre le génie et la folie. </livre> </livres> |
L'exemple montre comment deux éléments du même nom pour lesquels les attributs peuvent aussi avoir le même contenu, doivent pourtant se distinguer par un attribut défini comme ID. Un analyseur syntaxique qui interprète correctement XML doit annoncer une erreur si l'affectation de valeur à l'attribut isbn du deuxième enregistrement a la même valeur que dans le premier enregistrement.
Les affectations de valeur à un attribut du type ID doivent correspondre aux règles pour les noms! Dans l'exemple ci-dessus, c'est pour cette raison qu'on a fait précéder le numéro isbn de la chaîne de caractères nr_ étant donné que le numéro ISBN proprement-dit commence par un chiffre, ce ne serait pas un nom valable.
L'Explorer Internet MS qui avec l'ancien analyseur syntaxique XML de Microsoft accepte certes le type ID, mais en tolérant plusieurs valeurs identiques ID dans le même document ce qui n'est pas le but recherché. Les analyseurs syntaxiques XML plus récents de Microsoft (à partir de msxml3.dll) se comportent par contre correctement.
|
|
Attributs avec une valeur d'identification de référenceQuand vous définissez pour des types d'élément des attributs avec une valeur d'identification, vous pouvez aussi définir des attributs dont la valeur renvoie à un autre élément déterminé. De cette façon, vous pouvez grâce aux attributs définir des relations de dépendance entre des éléments.
<!ELEMENT liste (point)*> <!ELEMENT point (#PCDATA)> <!ATTLIST point nom ID #REQUIRED point_parent IDREF #IMPLIED > |
Dans l'exemple un type d'élément point est défini. Ce type d'élément pourrait par exemple accepter les différents points d'un index du contenu qui définit des structures de chapitres arborescentes. Cette dépendance est exprimée dans l'exemple dans la définition des attributs. Le type d'élément point reçoit un attribut nom qui est défini comme attribut avec une valeur d'identification. Chacun des éléments point de l'application doit donc se voir affecter une valeur claire et sans ambiguïté pour nom.
De plus un attribut point_parent est affecté à l'élément point. La valeur de cette attribut doit être d'après la définition le nom d'un point auquel l'élément actuel se réfère. De telles relations récurrentes s'expriment par l'identificateur clé IDREF. Grâce aux deux attributs définis, il est maintenant possible de former une arborescence de votre choix.
Exemple d'affichage: aperçu (un navigateur XML affiche par exemple la structure de données)
<?xml version="1.0" encoding="ISO-8859-1" ?> <!DOCTYPE liste SYSTEM "liste.dtd"> <liste> <point nom="racine">contenu</point> <point nom="introduction" point_parent="racine">introduction</point> <point nom="histoire" point_parent="introduction">histoire</point> <point nom="aujourd_hui" point_parent="introduction">etat_actuel</point> <point nom="pas" point_parent="racine">premiers pas</point> <point nom="exemple" point_parent="pas">un petit exemple</point> </liste> |
L'exemple montre comment vous pouvez former une arborescence avec la seule aide des deux attributs nom (défini en tant qu'ID) et point_parent (défini en tant qu'IDREF). La structure de l'exemple pourrait être visuellement représentée ainsi:
contenu
introduction
histoire
etat_actuel
premiers pas
un petit exemple
L'attribut point_parent dans l'exemple est défini comme facultatif (#IMPLIED. C'est pourquoi il peut par exemple être omis dans le premier point de l'exemple (le point nommé racine).
Outre IDREF il existe pour la définition d'attributs avec une valeur d'identification également la forme plurielle IDREFS. Grâce à elle vous permettez que plusieurs valeurs de référence claire soient attribuées à un tel attribut. Si dans l'exemple ci-dessus on définissait par exemple:
point_parent IDREFS #REQUIRED
Alors on permettrait dans l'application une affectation telle que celle-ci:
<point nom="pas" point_parent="racine introduction">premiers pas</point>
Séparez plusieurs affectations par des espaces pour le faire.
L'Explorer Internet MS avec l'ancien analyseur syntaxique XML de Microsoft accepte certes le type ID, mais en tolérant plusieurs valeurs identiques ID dans le même document ce qui n'est pas le but recherché. Les analyseurs syntaxiques XML plus récents de Microsoft (à partir de msxml3.dll) se comportent par contre correctement.
|
|
Attributs avec une valeur d'entité (par exemple pour des références de fichier externe)Pour les attributs avec une valeur d'entité l'affectation de valeur à un tel attribut dans l'application est reconnue en tant que nom d'une Entité pour blocs de texte et transcriptions définie. La valeur affectée n'est alors pas le nom noté mais la définition qui lui est reliée. Cette possibilité est avant tout intéressante parce qu'elle est en XML la façon de référencer des fichiers externes. Imaginez-vous une notation telle que <image source="toile.gif">. Pour faire savoir à l'analyseur syntaxique que ce contenu d'attribut ne doit pas seulement être interprété comme une simple chaîne de caractères mais comme référence d'un fichier externe, un détour par la référence définie comme entité externe est indispensable.
<!NOTATION gif PUBLIC "+//ISBN 0-7923-9432-1::Graphic Notation//NOTATION CompuServer Graphic Interchange Format//EN"> <!ENTITY toile SYSTEM "toile.gif" NDATA gif> <!ELEMENT image EMPTY> <!ATTLIST image source ENTITY #REQUIRED > |
Comme vous le voyez, l'incorporation d'une référence externe est un peu compliquée. Dans la DTD, mentionnez aussi bien la source du fichier à référencer que la manière dont le type de fichier correspondant doit être traité. Définissez la source avec l' entité pour ressource externe (<!ENTITY...>), le traitement du type de fichier avec la notation de fichier référencé (<!NOTATION...>). Dans l'exemple un type d'élément nommé image est défini avec un attribut nommé source. Pour définir un attribut avec une valeur d'entité, notez dans la définition à la place de CDATA l'identificateur-clé ENTITY.
Exemple d'affichage: aperçu (un navigateur XML affiche par exemple la structure de données)
<?xml version="1.0" encoding="ISO-8859-1" ?> <!DOCTYPE image SYSTEM "image.dtd"> <image source="toile" /> |
L'application est toute simple: Un nom est affecté à l'élément image par l'attribut source. Ce nom est défini comme entité dans la DTD. L'analyseur syntaxique apprend par la définition comme attribut avec valeur d'entité, qu'il doit interpréter la valeur affectée comme le nom d'une entité. Lors de l'interprétation, la valeur affectée "toile" est remplacée par le lien qui lui a été affecté "toile.gif". Par la définition comme entité externe (avec SYSTEM) l'analyseur syntaxique sait en outre que cette valeur représente la mention de chemin d'un autre fichier.
Le moyen décrit ici n'est pas une solution si vous voulez obtenir qu'à un attribut une source externe de votre choix puisse être affectée, comme c'est possible par exemple en HTML avec <img src="...">. Ce genre de chose ne peut pas du tout être défini en XML à l'heure actuelle. En XHTML, la définition conforme à XML de HTML, l'attribut src de l'élément img est simplement défini comme CDATA. Si un navigateur Web comprend cet attribut comme l'ordre d'afficher le graphique à l'endroit correspondant n'est dû qu'a la programmation même du navigateur Web - cela ne figure pourtant pas dans la DTD XHTML! Quand vous voulez sortir directement à l'écran des données XML, les références externes de votre choix sont un problème. Une possibilité de résoudre ce problème est donnée par XSLT à l'aide duquel vous pouvez transcrire des données XML en HTML avant la sortie de ces données.
En plus d'ENTITY existe encore pour la définition d'attributs la forme plurielle ENTITIES. Grâce à elle, vous permettez qu'à un tel attribut plusieurs noms d'entités puissent être affectés. Pour le faire, séparez plusieurs affectations par des espaces.
|
|
Attributs avec valeur de nomDe tels attributs attendent comme valeur un nom qui cependant, à la différence des attributs avec une valeur d'identification ne doivent pas être uniques pour tout le document. Le nom ne peut pas contenir d'espace et doit commencer par une lettre, un chiffre ou l'un des signes . (point), - (trait d'union), _ (tiret de soulignement) ou bien : (deux points).
<!ELEMENT jours_feries (jour_ferie)*> <!ELEMENT jour_ferie EMPTY> <!ATTLIST jour_ferie date NMTOKEN #REQUIRED occasion CDATA #REQUIRED > |
Dans l'exemple, une liste d'attributs avec deux attributs date et occasion ont été définis pour un élément jour_ferie. L'attribut date a quant à lui une valeur de nom. C'est ce qu'on obtient par le mot-clé NMTOKEN.
Exemple d'affichage: aperçu (un navigateur XML affiche par exemple la structure de données)
<?xml version="1.0" encoding="ISO-8859-1" ?> <!DOCTYPE jours_feries SYSTEM "jours_feries.dtd"> <jours_feries> <jour_ferie date="6.01" occasion="Épiphanie" /> <jour_ferie date="1.05" occasion="Fête du travail" /> <jour_ferie date="25.12" occasion="Noël" /> </jours_feries> |
L'exemples définit trois jours fériés avec la date et l'occasion. Les valeurs des attributs date correspondent tout à fait aux règles permises pour le type NMTOKEN. Dans la pratique on utilise aussi volontiers ce type d'attribut pour travailler avec des valeurs numériques ID étant donné que les attributs avec valeur d'identification ne tolèrent aucun chiffre au début de l'affectation de valeur.
En plus de NMTOKEN existe encore pour la définition d'attributs la forme plurielle NMTOKENS. Grâce à elle, vous permettez qu'à un tel attribut plusieurs noms puissent être affectés. Pour le faire, séparez plusieurs affectations par des espaces.
|
|
Vous connaissez probablement en HTML des constructions telles que <hr noshade> ou bien <td nowrap>. Donc des attributs autonomes sans affectation de valeur. Ce genre d'attributs n'existe pas dans la syntaxe XML. XML prévoit qu'à chaque attribut une valeur soit affectée. Chaque attribut doit recevoir lors de la définition au moins le type de contenu indéfini CDATA. Étant donné que des attributs tels que noshade ne sont ni plus ni moins qu'une abréviation pour quelque chose comme noshade="yes", il est recommandé pour la définition de tels attributs de travailler avec des attributs avec des valeurs au choix invariables.
|
|
Exemple lié au contexte: Description de personneLes personnes ont de nombreuses propriétés et c'est pourquoi une description de personne est le cas rêvé d'application typique pour la mise en œuvre d'attributs. Toutefois, lors de la transcription en XML, vous devez tenir compte des réflexions développées dans la partie sur les généralités sur les attributs.
L'exemple suivant montre un concept de données pour lequel toutes les données utiles sont sauvegardées dans des attributs.
<!ELEMENT fichier_personnel (personne)*> <!ELEMENT personne (bio,socio)> <!ATTLIST personne nom CDATA #REQUIRED > <!ELEMENT bio (yeux,cheveux,peau,poids,groupe_sanguin)> <!ELEMENT yeux EMPTY> <!ATTLIST yeux couleur CDATA #REQUIRED > <!ELEMENT cheveux EMPTY> <!ATTLIST cheveux couleur CDATA #REQUIRED remarque CDATA #IMPLIED > <!ELEMENT peau EMPTY> <!ATTLIST peau couleur CDATA #REQUIRED remarque CDATA #IMPLIED > <!ELEMENT poids EMPTY> <!ATTLIST poids kg CDATA #REQUIRED > <!ELEMENT groupe_sanguin EMPTY> <!ATTLIST groupe_sanguin type (A|B|0|AB) #REQUIRED > <!ELEMENT socio (langue,etat_civil,passeport)> <!ELEMENT langue EMPTY> <!ATTLIST langue lang CDATA #REQUIRED abr (de|en|fr|es|pt|it) #IMPLIED > <!ELEMENT etat_civil EMPTY> <!ATTLIST etat_civil type (celibataire|marie|veuf) #REQUIRED > <!ELEMENT passeport EMPTY> <!ATTLIST passeport nr NMTOKEN #REQUIRED > |
Exemple d'affichage: aperçu (un navigateur XML affiche par exemple la structure de données)
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE fichier_personnel SYSTEM "fichier_personnel.dtd">
<fichier_personnel>
<personne nom="Prosper Têtedeuf">
<bio>
<yeux couleur="bleugris" />
<cheveux couleur="blonds" remarque="parfois teints" />
<peau couleur="blanche" />
<poids kg="74" />
<groupe_sanguin type="A" />
</bio>
<socio>
<langue lang="française" abr="fr" />
<etat_civil type="marie" />
<passeport no="38385409398" />
</socio>
</personne>
</fichier_personnel>
|
L'exemple de DTD définit un type d'élément document fichier_personnel qui peut contenir autant d'éléments du type personne qu'il est souhaité. Ce type d'éléments est constitué de son côté avec un contenu d'éléments. Par ailleurs le type d'élément personne reçoit toujours l'attribut indispensable nom, dans lequel le nom de la personne doit être noté. Les deux types d'éléments bio et socio, qui représentent le contenu de l'élément personne sont eux-mêmes des types d'éléments avec un contenu d'éléments. Le type d'élément bio est constitué par la suite fixe de types d'éléments yeux,cheveux,peau,poids,groupe_sanguin, et le type d'élément socio par la suite fixe de types d'éléments langue,etat_civil,passeport. De cette manière, on obtient un enregistrement structuré personne.
Les types d'éléments subordonnés sont tous définis sans exception comme des éléments sans contenu grâce au mot-clé EMPTY. Cependant des attributs sont définis pour tous ces types d'éléments dans lesquels, dans l'application, les données peuvent être sauvegardées. La plupart de ces attributs sont définis comme des attributs indispensables à l'aide du mot clé REQUIRED, quelques uns comme attributs facultatifs avec IMPLIED (voir attributs obligatoires et facultatifs).
Dans l'application en exemple on reconnaît la notation typique de repères sans repères de fermeture (sur la notation de ces éléments, voir aussi la partie sur les repères, attributs et affectations de valeur). Le fichier d'exemple fichier_personnel.xml contient dans l'exemple exactement un enregistrement personne. Le fichier pourrait cependant d'après la définition DTD contenir le nombre d'enregistrements que vous souhaitez, avec toutefois l'obligation pour tous les enregistrements d'adopter la même construction d'élément.
|
| |
 |
Entités pour blocs de texte et transcriptions
|
 |
Éléments et règles d'imbrication
|
| SELFHTML/Aides à la navigation XML/DTD Définitions de type de document (DTD) |
© 2001 Stefan Münz / © 2003 Traduction 
Serge François, 13405@free.fr selfhtml@fr.selfhtml.org
