7 — Valider & comparer

Les chapitres précédents portaient sur un fichier à la fois. Celui-ci répond aux questions qui portent sur l'ensemble de votre travail :

• ce document est-il conforme à son schéma ?
• tout mon dossier est-il encore sain, ou ai-je cassé quelque chose ?
• cette sortie est-elle identique à celle d'hier ?
• mes transformations font-elles toujours ce qu'elles sont censées faire ?

Quatre outils y répondent : la validation contre un schéma, la validation par lot, la comparaison structurelle et les tests XSpec. Tous fonctionnent hors ligne.

7.1 Valider le fichier actif

Le bouton Valider le fichier actif de la barre d'outils contrôle l'onglet courant à la demande : bonne formation du XML, compilation d'une feuille de style, conformité au schéma associé.

Il est indépendant du réglage Validation en direct : même détection coupée, il répond. Si le fichier est sain, une confirmation vous l'annonce — « Le fichier "…" ne contient aucune erreur de syntaxe. »

La validation au fil de la frappe, les soulignements ondulés et l'association d'un schéma sont traités au chapitre Éditer §2.3 et §2.5.

7.2 Valider contre un schéma XSD ou une DTD

Le bouton Valider un XML contre un schéma (XSD ou DTD) déroule un menu de trois entrées. Les deux premières valident ; la troisième, Associer un schéma, se contente de lier (chapitre Éditer §2.3).

Le dialogue

XSD ouvre Validation XSD — Valider un fichier XML contre un schéma XSD — avec deux listes :

DTD ouvre le dialogue jumeau, Validation DTD, avec le champ DTD :.

Les deux listes se remplissent depuis le workspace ouvert. S'il n'y a rien à proposer, l'application le dit plutôt que d'ouvrir un dialogue vide : Aucun fichier XML trouvé dans le workspace, Aucun schéma XSD trouvé dans le workspace, Aucune DTD trouvée dans le workspace.

Ce que vous voyez

Le bouton se grise le temps du contrôle — un seul à la fois — et la console trace toute l'opération, préfixée [XSD] ou [DTD] :

[XSD] --- Lancement de la validation XSD ---
[XSD] XML : C:\...\data.xml
[XSD] XSD : C:\...\catalogue.xsd
[XSD] ✓ "data.xml" est valide selon "catalogue.xsd"

En cas d'échec, la console annonce le nombre — ✗ Validation échouée : 3 problème(s) détecté(s) —, le message d'état résume — Validation XSD échouée : 3 problème(s) — et les erreurs sont posées en soulignement ondulé dans le document, à la ligne et à la colonne exactes. Toutes les erreurs sont remontées, pas seulement la première.

Valider, c'est associer

Une validation lancée depuis XSD ou DTD mémorise le lien entre les deux fichiers. La console le confirme :

[XSD] Association mémorisée : data.xml -> catalogue.xsd

À partir de cet instant, le document est validé en direct contre ce schéma et la complétion en est pilotée, sans autre geste de votre part. C'est le raccourci le plus rapide pour équiper un document.

7.3 Valider un dossier entier

Une validation fichier par fichier ne dit pas si votre projet est sain. La validation par lot, elle, balaie une arborescence complète en une passe.

• Clic droit sur un dossier de l'explorateur → Valider le dossier ;
• clic droit sur la zone vide de l'explorateur → Valider le workspace.

L'onglet Problèmes du panneau bas passe au premier plan. Avant tout usage il affiche Clic droit sur un dossier de l'explorateur pour le valider.

Ce qui est contrôlé

Le balayage est récursif et traite chaque type selon sa nature :

Pendant et après

La progression s'affiche en continu — Validation… 12/57 — et le bouton Annuler interrompt à tout moment : l'arbre reste figé sur ce qui a déjà été vu, et le statut passe à Validation annulée.

Le bilan prend l'une de ces formes :

L'arbre ne liste que les fichiers en erreur — un dossier sain donne un arbre vide, pas une liste de coches. Un simple clic sur un problème ouvre le fichier et surligne la ligne fautive.

Le lot lit le disque

C'est la différence de fond avec la validation au fil de la frappe :

La validation par lot reflète l'état du disque au moment où vous la lancez. Vos modifications non enregistrées n'y sont pas.

Elle ne vous laisse pas vous tromper pour autant : un fichier dont un onglet est ouvert et modifié porte le badge non enregistré. Le résultat affiché ne correspond alors pas à ce que vous voyez dans l'éditeur — enregistrez et relancez.

7.4 Résoudre les schémas hors ligne — les catalogues XML

Certains documents ne se valident pas sur un poste sans réseau, non parce qu'ils sont fautifs, mais parce qu'ils désignent leurs schémas par des identifiants plutôt que par des chemins : un xsi:schemaLocation qui pointe sur une URL, un DOCTYPE … PUBLIC, un xsl:include par URL logique.

Un catalogue XML (OASIS 1.1) est le fichier qui fait le lien entre ces identifiants et vos fichiers locaux.

Déclarer un catalogue

Deux entrées :

• Paramètres → Catalogues XML… ouvre le dialogue Catalogues XML (OASIS) ;
• clic droit sur un .xml de l'explorateur → Utiliser comme catalogue XML.

Le dialogue présente la liste Catalogues (ordre = priorité) :

Si votre workspace contient un catalog.xml à sa racine, il est détecté automatiquement et apparaît coché, avec la mention catalog.xml auto-détecté (non persisté). Il agit déjà. Dès que vous le touchez — décocher, retirer, ajouter un second catalogue — votre choix est mémorisé et survit au redémarrage.

Ce que cela débloque

Une fois un catalogue actif, la résolution s'applique partout, pas seulement à la validation :

La navigation et la vue Hiérarchie suivent également : F12 sur un template déclaré dans un module inclus par URL logique vous y emmène.

La trace et le garde-fou

Les événements de catalogue partent en console, préfixés [Catalog] :

[Catalog] catalog.xml auto-détecté à la racine : C:\...\catalog.xml (non persisté)
[Catalog] 2 catalogue(s) actif(s) (génération 3)

Deux messages méritent attention :

• [Catalog] Cible non-locale ignorée (mode hors ligne) : http://… — un catalogue a réécrit un identifiant vers une adresse réseau. Elle n'est jamais suivie. Debug XML Tool ne sort pas de votre poste, même si un catalogue le lui demande ;
• [Catalog] Catalogue invalide, ignoré : … — … — un catalogue mal formé est écarté seul ; les autres restent actifs.

Sans catalogue déclaré, rien ne change. La résolution des schémas reste exactement celle des chapitres précédents. Les catalogues n'ajoutent une étape que si vous en configurez un.

Les catalogues sont mémorisés par workspace : deux projets ont chacun les leurs.

7.5 Comparer deux fichiers

Ma sortie a-t-elle changé ? Et si oui, où ?

Deux entrées :

• le bouton Comparer deux fichiers (diff XML structurel) de la barre d'outils, qui demande successivement Comparer — premier fichier puis Comparer — second fichier ;
• clic droit sur un fichier de l'explorateur → Comparer avec… — le premier est déjà désigné, seul le second vous est demandé.

Ce qui s'ouvre

Un onglet d'éditeur nommé source.xml ↔ reference.xml affiche les deux fichiers côte à côte, en lecture seule, différences surlignées et repérées dans la marge.

En parallèle, l'onglet Comparaison du panneau bas passe au premier plan et liste les différences une à une :

Double-cliquez une ligne : la différence est révélée dans le bon volet de l'onglet de comparaison.

Le statut du panneau résume :

Le verdict part aussi en console : Comparaison source.xml : 2 différence(s) structurelle(s).

Structurelle, pas ligne à ligne

C'est ce qui distingue cet outil d'un diff ordinaire, et c'est le point à retenir :

Deux documents qui ne diffèrent que par leur indentation, l'ordre de leurs attributs, leurs commentaires ou leurs préfixes d'espaces de noms sont déclarés identiques.

Reformater une sortie ne produit donc aucun bruit. Vous ne voyez que ce qui change vraiment : un élément, un attribut, un texte.

Si l'un des fichiers n'est pas du XML, ou est mal formé, la comparaison se replie sur une comparaison textuelle et vous le signale explicitement — elle ne prétend pas avoir fait mieux.

7.6 Comparer une sortie à sa référence

Le cas d'usage le plus utile de la comparaison est le test de non-régression : figer une sortie correcte, puis vérifier après chaque modification que la nouvelle lui est identique.

Il est intégré aux scénarios de transformation (chapitre Transformer & exporter §3.7) : renseignez le champ Sortie de référence :, puis utilisez le bouton Exécuter et comparer. La transformation est relancée et son résultat est comparé à la référence, avec le même moteur structurel qu'au §7.5.

Le verdict s'affiche en console :

7.7 Exécuter des tests XSpec

XSpec est le framework de tests unitaires de référence pour XSLT. Debug XML Tool l'exécute directement, sans installation ni réseau : le moteur est embarqué.

Lancer les tests

Clic droit sur un fichier .xspec de l'explorateur → Exécuter les tests XSpec. L'onglet XSpec du panneau bas passe au premier plan. Avant tout usage, il affiche Clic droit sur un fichier .xspec pour exécuter les tests.

Le badge donne le compte : 2 ✔ / 1 ✘ / 1 ⏸ — réussis, échoués, ignorés.

L'arbre présente les scénarios, chacun développable en tests, avec l'icône de son statut. Les scénarios en échec sont développés d'emblée ; les autres restent repliés. Vous voyez donc d'abord ce qui ne va pas.

Un simple clic sur un scénario ou un test ouvre le .xspec et surligne la ligne de son label — vous êtes sur la déclaration du test, pas sur un rapport.

Comprendre un échec

Sélectionnez un test en échec : une zone de détail apparaît sous l'arbre, en deux colonnes, Attendu et Obtenu.

Quand la différence n'est pas lisible à l'œil, le bouton Comparer attendu/obtenu ouvre les deux résultats dans la comparaison structurelle du §7.5 — mêmes colonnes, même navigation.

Le bouton Relancer rejoue la campagne sans repasser par l'explorateur.

Créer un fichier de test

Clic droit sur un .xsl ou un .xslt → Générer un squelette XSpec. Un fichier nom.xspec est créé à côté de la feuille de style et ouvert immédiatement ; la console le confirme — Squelette XSpec créé : …. Vous n'avez plus qu'à remplir les scénarios.

Un .xspec mal formé ne casse rien : le panneau affiche Erreur XSpec : … et reste utilisable pour le run suivant.

Les tests n'interfèrent pas avec le débogueur. Ils s'exécutent sur un moteur séparé : le badge d'état reste IDLE, vos points d'arrêt ne sont pas atteints, et une session de débogage en cours n'est pas perturbée.

7.8 Limites à connaître

• La validation XSD suit la norme W3C XML Schema 1.0.
• La validation par lot reflète le disque, jamais vos buffers — les onglets concernés sont signalés par le badge non enregistré.
• Les modules xsl:include sont validés isolément par le lot : un module qui n'a de sens qu'importé dans une feuille principale peut y apparaître en erreur à tort.
• Le lot ignore les fichiers de plus de 2 Mo — ils sont comptés dans le bilan — et plafonne l'affichage à 10 000 problèmes (— affichage tronqué). Ses résultats ne sont pas conservés d'une session à l'autre.
• La comparaison tient l'ordre des éléments pour significatif : deux documents contenant les mêmes éléments dans un ordre différent sont différents.
• Au-delà de 10 Mo, la comparaison se replie sur le mode textuel, et l'affichage est plafonné à 5 000 différences.
• Pas de comparaison de dossiers, pas de fusion : la comparaison montre, elle ne réconcilie pas.
• Les catalogues ne résolvent que vers des fichiers locaux. Toute cible réécrite vers une adresse réseau est ignorée et tracée — c'est le prix du fonctionnement 100 % hors ligne.
• Un scénario XSpec ne se débogue pas encore pas-à-pas : les tests s'exécutent, mais les points d'arrêt ne s'y appliquent pas.

Et ensuite

• Référence — tous les raccourcis, boutons, menus et gestes, en tables.
• Analyser — profileur, couverture des templates, back-mapping.
• Transformer & exporter — scénarios et sorties de référence.