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) |
Vous avez toujours besoin d'une DTD quand vous désirez des données XML qui ne soient pas seulement 
conformes, mais qui soient également valides. Car "valide" signifie: pouvant être validées au vu d'une DTD.
Il n'est pas indispensable qu'un fichier XML soit "valide" et qu'il possède une DTD correspondante. Le critère de validité est en fin de compte la "grande école" de XML et l'état idéal. Dans de nombreux cas pratiques il n'est pas du tout nécessaire d'avoir une DTD, par exemple quand on a juste besoin d'un format de données correct qui n'est cependant pas interprété par le moindre analyseur syntaxique, qui teste toujours la validité au vu d'une DTD. Si donc vous ne voulez par exemple que sauvegarder les données sous une forme conforme à XML pour les traiter avec un 
script CGI, qui traduit le code XML et ses commandes propres en code HTML pour le navigateur, alors vous n'avez pas besoin à vrai dire de DTD et vous pouvez omettre la déclaration de type de document.
Cependant, la création d'une DTD est judicieuse quand le temps le permet. Car la DTD est, - même quand les données ne sont pas testées quant à leur validité pendant le processus de traitement - dans tous les cas une documentation sur les prévisions à atteindre pour les données. En particulier quand les stocks de données sont conservés sur de longues périodes et manipulées ou modifiées par des personnes différentes, une DTD est un document de base important pour les normes assurant l'exactitude et l'homogénéité des données.
Même en regard des traitements multiples des données, une DTD est précieuse ("publication multiple à partir d'une seule et même source"). Car ce n'est que lorsque toutes les précautions sont prises pour que toutes les règles définies soient respectées lors de la saisie des données, que des programmes peuvent traiter ces données sans risque de perte.
 
|
En général, il est toujours avantageux de s'en tenir à des standards déjà existants. XML permet certes la création de ses propres DTD mais il y a toujours le danger que la roue soit à nouveau inventée. Avant de prendre la décision de développer une nouvelle DTD personnelle importante, vous devez vous faire une idée des DTD publiques accessibles déjà existantes. Un récapitulatif des langages XML connus développés par le consortium W3 peut être consulté dans la partie sur les Langages standard XML importants: SVG, MathML, SMIL, RDF, WML.
Mais même lorsque vous développez vos propres DTD, vous ne devez pas développer une DTD entièrement nouvelle avec tout ce qui s'en suit pour chaque application. Le concept des DTD prévoit à vrai dire la possibilité d'utiliser les DTD modulaires. Ce qui signifie que vous pouvez vous écrire des DTD pour certaines tâches et les incorporer ensuite dans d'autres DTD. Il est ainsi possible d'écrire des DTD "allégées" qui contiendront pourtant des concepts de données très complexes parce qu'elles se composent d'autres DTD élémentaires. Dans une entreprise, il est par exemple judicieux de réfléchir à ces DTD modulables. Les réflexions à faire à ce sujet, ressemblent à celles qu'il faut faire pour la création de grandes bases de données relationnelles. Il s'agit là en fin de compte de normalisation des données.
Dans la partie traitant des DTD modulaires à l'aide d'entités le principe pour incorporer des DTD dans d'autres DTD est décrit.
Avec les DTD connues publiques, l'avantage est que la plupart du temps existent déjà des logiciels de traitement par exemple des scripts de transcription en HTML, Postscript ou bien MIF. Les langages XML comme SVG par exemple peuvent entre-temps être traités par des programmes graphiques connus. Avec le développement d'une DTD ce n'est la plupart du temps pas le cas - en règle générale on a besoin de plus de logiciels qu'un simple analyseur syntaxique, qui ne fait que vérifier les données à l'exclusion de toute autre chose. Vous avez tout au moins besoin en général de feuilles de style ou de scripts pour la représentation de données XML. La somme de travail qui est liée à des DTD importante est très vite comparable à celle qui est liée au développement d'une solution logicielle sur mesure.
|
|
Il faut privilégier les DTD internes pour des petits projets dont les données ne se trouvent que dans ce seul et unique fichier. Pour des projets plus importants pour lesquels plusieurs ou de nombreux fichiers ase réfèrent à une DTD commune, vous devez à tout prix créer une DTD externe.
|
|
De la même façon que certains préconisent des structures de répertoires simples et d'autres des structures de répertoires fortement imbriqués, ils y a les partisans qui séparent les données et les DTD et les autres qui veulent tout regrouper. On peut certainement trouver des arguments pour les deux points de vue..
Il est important de se poser la question si l'accès à la DTD ne se fera qu'à partir de votre ordinateur ou bien d'un réseau local, ou bien si des utilisateurs devront mentionner cette DTD dans leurs données XML, par exemple par une adresse HTTP. Dans ce dernier cas la DTD doit être sauvegardée dans une arborescence de répertoires que le serveur Web utilise comme "racine pour les documents". Les DTD sauvegardées dans des fichiers séparés ont l'extension .dtd.
|
|
Pour la création d'une DTD, vous devez attribuer une quantité de noms - pour les éléments, pour les attributs et pour les entités. Abstraction faite que tous les noms attribués doivent satisfaire aux règles pour les noms, il est de bon ton de réfléchir auparavant à un concept de nom . Car même ai les utilisateurs qui veulent travailler avec une DTD disposent pour travailler sur leurs données d'un environnement Wysiwyg, ils seront pourtant confrontés aux noms d'éléments et d'attributs à leur disposition.
Pour les DTD qui doivent être utilisées sur le plan international, il est normalement préférable de n'attribuer que des désignations anglaises, donc par exemple chapter au lieu de chapitre ou bien name au lieu de nom.
Quelquefois il y a aussi des raisons de donner dans les noms, les noms d'auteur, de service, de firme, par exemple marketing-statement ou bien developer-statement.
Pour des quantités de données très importantes, la longueur des noms peut aussi jouer un rôle. Ainsi la différence entre les notations <carteidentificationpersonnel>...</carteidentificationpersonnel> et <cip>...</cip> 50 Byte, ce qui pour 1.000.000 d'enregistrements est multiplié en conséquence. Des noms plus longs ont cet avantage par rapport aux abréviations d'être plus compréhensibles. Les abréviations doivent toujours être commentées, par exemple dans la DTD sous forme de commentaires.
L'attribution de nom doit suivre un concept homogène. Ce n'est par exemple pas un bon style d'utiliser des majuscules et des minuscules dans quelques éléments et de ne pas le faire dans d'autres, par exemple Service, mais responsable. Étant donné que XML différencie majuscules et minuscules, l'attribution de noms doit suivre une variante d'un bout à l'autre.
|
|
La création d'une DTD est - bien qu'il ne s'agisse pas de "programmation" au sens de création de procédures - malgré tout comparable à du développement de logiciels. Pour des projets logiciels qui dépassent de simples petits scripts de travail, il n'est pas raisonnable d'y programmer sans relâche pour finir par remarquer en fin de compte qu'on y a trop peu réfléchi et pas assez prévu de possibilités d'extension. Il en va de même pour la création d'une conception de données. Normalement, les DTD sont créées pour régir une "classe de documents". C'est pourquoi la DTD doit être suffisamment souple pour satisfaire aux exigences actuelles et futures de cette classe de documents.
La première étape doit consister à examiner et à analyser les données existantes destinées à être sauvegardées à l'avenir sous la forme XML. Comment les structures de données typiques sont-elles construites? Existe-t il par exemple dans une série de manuels une suite de chapitre incontournable et qui revient sans arrêt? Qu'est-ce qui n'est pas homogène mais peut le devenir? y a-t-il par exemple, des manuels dans lesquels 5 niveaux de titre sont utilisés et d'autres qui n'en utilisent que 3? Quels points de repère invariables existent? Y a-t il par exemple des sections du manuel avec une construction fixe, par exemple une description des fonctions en introduction suivie d'une description des procédures puis de remarques? Une analyse des données existantes permet d'accéder à la conception des données.
Quand les données existantes sont évaluées, on doit aussi réfléchir de quelle manière ces données pourront plus tard être modifiées ou étendues. Est-il par exemple possible pour un type de manuel qui jusqu'ici ne décrivait que du matériel, puisse aussi à l'avenir servir à la description de logiciels? Quelles en seraient les conséquences pour la conception des données? Quels éléments de donnés doivent en pareil cas également être pries en compte? Personne ne peut certes prévoir complètement l'avenir mais une DTD devrait malgré tout prendre en compte toutes les éventualités possibles. Car si l'on attend que nombre de données basées sur une DTD soient créées, il peut être difficile de restructurer cette DTD.
Pour le développement de logiciels, il s'est instauré de décrire de différentes manières la façon de fonctionner du logiciel prévu avant même d'entreprendre la codification. Pour cela, il existe des procédés tels que les descriptions de fonctions, les diagrammes de déroulement etc... Il existe des approches générales et plus fines. Pour la création de DTD se sont développées au fil du temps des méthodes analogues. Le développement d'une DTD est constituée entre autres des phases suivantes:
Pour des DTD plus grandes ou des systèmes de DTD groupées, il peut être indiqué de visualiser les plans de la structure des données sous une forme simple et orthodoxe. Les dépendances hiérarchiques entre les éléments de données prévus peuvent être représentés sous forme par exemple d'un "index du contenu" numéroté, les rapports relationnels entre les données par des flèches par exemple.
Pour le développement de DTD les publications de Eve Maler et de Jeanne El Andaloussi sont aujourd'hui une référence (recherchez ces noms le cas échéant avec un moteur de recherche ou chez un service de livres comme 
Amazon!).
|
| |
 |
Règles de traitement pour les DTD
|
 |
Règles pour l'édition en XML et conventions de noms de fichiers
|
| 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
