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)