Voici quelques conseils pour la validation de vos fichiers XML. Je vous rappelle qu'il est utile d'utiliser un service de vérification sur le Web si votre outil ne le fait pas bien. Ici un exemple concret. Je me suis permis d'utiliser un exemple concret (Projet 21). (1) Dans son XML il y avait 3 erreurs (difficile à détecter à l'oeil nu) Les "end tag" et étaient mal tapés et il manquait un tag Voir: http://tecfa.unige.ch/staf/staf-f/staf18/test/err-demo/specification-err.xml Le vérificateur de XML.com (http://www.xml.com/xml/pub/tools/ruwf/check.html) nous dit ceci: Line 59, column 14: Encountered with no start-tag. Line 60, column 16: Encountered with no start-tag. Line 137, column 16: Encountered expected ...assumed ...assumed ...assumed La dernière ligne est assez difficile à interpréter, mais en gros le parseur arrive à la fin de la specification et cherche tjrs delivErable(s) et objectives. (2) Problème corrigé et on teste une nouvelle version: http://tecfa.unige.ch/staf/staf-f/staf18/test/err-demo/specification-err.xml Elle passe avec ce vérificateur, mais en fait il reste un grand problème. Les tags sont "EMTPY" donc il nous faut des et CA cet outil ne trouve pas. On regarde avec un outil beaucoup plus sévère: http://www.stg.brown.edu/service/xmlvalid/ La on tombe sur pleins d'erreurs, notamment au niveau des valeurs qui manquent dans les attibuts, mais il trouve également les faux . Les messages d'erreurs ne sont pas très sympas, mais chaque ligne est bien indiquée. Sans outil XML correct il est difficile de produire un XML valide, faites simplement ce que vous pouvez au niveau des attributs.... (3) Notez que XSLT n'exige pas des fichiers XML valides, il suffit qu'il soient "well formed". L'URL suivant marche: http://tecfa.unige.ch/staf/staf-f/staf18/proj/proj21/specification-err2.sxml Mais attention: - l'affichage via XSLT peut ne plus marcher si on ne respecte pas un schéma - certaines procédures ne vont certainement pas marcher, par exemple celle qui va calculer l'estimation totale du travail. Regardons l'exemple: L'attribut "man-days" doit être un NMTOKEN selon le DTD, c'est à dire un seul mot. En fait, il nous faut un nombre (par exemple 5). Mais aucun moyen d'exprimer cela avec un DTD, raison pour laquelle les DTD vont être abandonnés bientôt en faveur de XSchema. Morale: (1) Il existe des outils sur le Web qui testent si votre DTD est well-formed et valide. Un bon éditeur XML le fait aussi aussi bien que le simple validateur à xml.com (par exemple Xemacs). (2) Il ne faut pas forcément qu'un fichier soit "valide" pour qu'il puisse être traité par un moteur XSLT. Par contre vous risquez de perdre de l'information (votre style-sheet ne trouvera pas certains éléments ou les affiche mal) et les programmes écrits pour xtraire de l'information vont se "planter". salutations ! PS: Je vous rappelle qu'il existe un problème au niveau du serveur. Pour visualiser un changement dans votre fichier specification.xml il faut également changer le contenu du fichier xpecification.sxml (simplement le recopier suffit). On essaye de trouver une solution, mais on l'a pas encore. Le problème est le suivant: Tous les autres mécanismes XML qui permettent d'inclure un fichier dans un fichier veulent des fichiers sans DTD (notament le xinclude processor de Cocoon). Soit on vous fait ajouter/enlever le DTD, soit on attend que le développeur de ce module réagisse ... pour le moment on attend (car recopier un fichier demande moins de travail que ajouter/enlever un DTD) XML = technologie vielle et connue (pas de pb) XSLT = technologie cutting edge (quelques petits problèmes) xinclude = technologie bleeding edge (problèmes)