1. À quoi sert la validation XML
XML — un format très flexible, parfois même trop. Contrairement aux données fortement typées, XML "tolère" des erreurs, et si vous oubliez de fermer une balise, ou si quelqu'un écrit un mauvais nom d'attribut, le programme peut lancer une erreur lors du parsing… ou ne pas remarquer le problème du tout, ce qui est pire.
La validation par XSD (XML Schema Definition) est un moyen de s'assurer que votre fichier XML correspond exactement à un contrat décrit à l'avance : quels sont les noms des balises, dans quel ordre elles doivent apparaître, quels types elles ont, si elles sont obligatoires et combien il peut y en avoir. C'est comme un contrôle d'identité pour vos données — le schéma dit : "On ne vous laissera pas passer sans le champ requis ou si le champ n'a pas la bonne longueur !"
La validation est importante dans les systèmes d'entreprise, pour l'échange de données entre différentes applications, les API — partout où on ne veut pas accepter silencieusement des structures malformées.
XSD (XML Schema Definition) est un document XML séparé qui formalise la structure d'un autre XML. Dans un XSD vous décrivez : quelles balises sont autorisées, lesquelles sont obligatoires, quels sont les types d'attributs ou d'éléments enfants, des motifs pour les chaînes, des contraintes pour les nombres, voire des valeurs possibles (via des restrictions et des enumerations).
| XML | XSD (description de la structure) |
|---|---|
|
|
|
|
XSD est conceptuellement similaire à JSON Schema dans le monde JSON.
2. Exemple de XSD et XML associé
Exemple XML
<person age="23">
<name>Ivan</name>
<email>ivan@example.com</email>
</person>
Exemple XSD
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="person">
<xs:complexType>
<xs:sequence>
<xs:element name="name" type="xs:string"/>
<xs:element name="email" type="xs:string" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="age" type="xs:positiveInteger" use="required"/>
</xs:complexType>
</xs:element>
</xs:schema>
Ce que décrit ce schéma :
- L'élément racine — <person>.
- À l'intérieur de <person> doivent se trouver les éléments <name> (obligatoire) et <email> (optionnel).
- <person> doit avoir l'attribut age avec une valeur entière positive.
3. Validation XML avec XSD en .NET
En .NET, la méthode classique consiste à utiliser les namespaces System.Xml et System.Xml.Schema.
Schéma de fonctionnement :
- Charger le fichier XML
- Charger le schéma XSD
- "Attacher" le schéma à la validation XML
- Lancer le processus de validation et traiter les erreurs éventuelles
Voici un exemple basique :
using System;
using System.IO;
using System.Xml;
using System.Xml.Schema;
// 1. Handler des erreurs de validation
void ValidationCallBack(object? sender, ValidationEventArgs e)
{
Console.WriteLine($"Erreur de validation : {e.Message}");
}
string xmlPath = "person.xml";
string xsdPath = "person.xsd";
// 2. On charge le schéma
XmlSchemaSet schemas = new XmlSchemaSet();
schemas.Add("", xsdPath);
XmlReaderSettings settings = new XmlReaderSettings();
settings.Schemas = schemas;
settings.ValidationType = ValidationType.Schema;
settings.ValidationEventHandler += ValidationCallBack;
// 3. On ouvre le XML avec les settings
using XmlReader reader = XmlReader.Create(xmlPath, settings);
while (reader.Read())
{
// On parcourt simplement le document - la validation se fait "à la volée"
}
Console.WriteLine("Validation terminée !");
Explications :
- Toutes les erreurs de validation seront capturées dans le callback ValidationCallBack.
- Si aucune erreur — le document correspond au schéma (ValidationType.Schema).
- En cas de non-conformités (attribut age manquant, email invalide, champ superflu, etc.) — elles apparaîtront dans la console.
Différents types d'erreurs et feedback
La validation XSD peut "se plaindre" pour plusieurs raisons. Voici les scénarios les plus courants et des exemples d'erreurs :
- Élément obligatoire manquant (minOccurs="1" par défaut)
- Balise en trop, non décrite dans le XSD
- Attribut de type incorrect (age="abc" au lieu d'un nombre)
- Chaînes ne correspondant pas au pattern (décrit via <xs:pattern>)
Erreur typique :
Erreur de validation : L'élément 'age' avec le contenu texte 'abc' n'est pas valide. Une valeur de type 'xs:positiveInteger' était attendue.
4. Schémas XSD plus avancés : types, enumerations, patterns
XSD est presque un langage pour décrire les données autorisées. Voilà quelques exemples avancés :
Énumération des valeurs acceptées
<xs:element name="gender">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="male"/>
<xs:enumeration value="female"/>
<xs:enumeration value="diverse"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
Contrainte de longueur pour une chaîne
<xs:element name="code">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:length value="8"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
Pattern pour l'email (simplifié)
<xs:element name="email">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value="\w+@\w+\.\w+"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
Vous pouvez créer vos propres types, les hériter, utiliser des éléments imbriqués — quasiment comme en OOP !
5. Validation d'un document complexe
Supposons que notre application d'apprentissage exporte maintenant une liste d'étudiants en XML. Un peu de code !
Exemple XML
<students>
<student id="1">
<name>Elena</name>
<grade>5</grade>
</student>
<student id="2">
<name>Alexey</name>
<grade>4</grade>
</student>
</students>
Schéma XSD
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="students">
<xs:complexType>
<xs:sequence>
<xs:element name="student" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="name" type="xs:string"/>
<xs:element name="grade">
<xs:simpleType>
<xs:restriction base="xs:integer">
<xs:minInclusive value="1"/>
<xs:maxInclusive value="5"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:sequence>
<xs:attribute name="id" type="xs:integer" use="required"/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
Validation dans le code (mêmes techniques) :
// Chemins vers les fichiers
string xmlPath = "students.xml";
string xsdPath = "students.xsd";
XmlSchemaSet schemas = new XmlSchemaSet();
schemas.Add("", xsdPath);
XmlReaderSettings settings = new XmlReaderSettings();
settings.Schemas = schemas;
settings.ValidationType = ValidationType.Schema;
settings.ValidationEventHandler += ValidationCallBack;
using XmlReader reader = XmlReader.Create(xmlPath, settings);
while (reader.Read()) { /* comme avant */ }
6. Nuances utiles
Comment indiquer le schéma directement dans le XML (xsi:schemaLocation)
En pratique, on rencontre souvent des fichiers XML qui ont directement dans l'élément racine les attributs xsi:schemaLocation ou xsi:noNamespaceSchemaLocation :
<students xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="students.xsd">
...
</students>
Ça ne valide pas le fichier "automatiquement", mais ça aide certains validateurs et éditeurs à trouver le schéma pour la vérification. Pour la validation .NET ce n'est pas obligatoire, mais c'est formellement correct.
Validation "à la volée" et en mémoire — avec XDocument
Si vous travaillez avec LINQ to XML (XDocument), vous pouvez aussi valider le document XML en mémoire, sans utiliser de fichiers :
using System.Xml.Linq;
using System.Xml.Schema;
// Chargement du schéma
XmlSchemaSet schema = new XmlSchemaSet();
schema.Add("", "students.xsd");
// Chargement du XML en mémoire
XDocument doc = XDocument.Load("students.xml");
// Validation
doc.Validate(schema,
(o, e) => Console.WriteLine($"Erreur : {e.Message}"),
true // Vérifier les warnings (souvent verbeux)
);
Cette approche est pratique si vous créez ou modifiez le XML par code et voulez vous assurer de ne pas générer un monstre XML qui viole le schéma.
7. Erreurs typiques lors de la validation XML avec XSD
Erreur n°1 : on a oublié d'ajouter le schéma ou le chemin vers le XSD est incorrect.
En conséquence, aucune validation n'est effectuée, et le fichier XML "passe à travers la garde", même s'il contient des erreurs. Souvent le chemin est relatif et l'application cherche le fichier ailleurs que prévu. Pour les tests, mieux vaut utiliser un chemin absolu ou placer le schéma à côté de l'exécutable.
Erreur n°2 : les namespaces ne correspondent pas.
Si votre schéma utilise un namespace, vous devez le passer en deuxième argument lors de l'ajout du schéma dans XmlSchemaSet.Add. Sinon la validation échouera même si la structure XML est correcte. Si aucun namespace n'est utilisé — passez une chaîne vide.
Erreur n°3 : ordre des éléments incorrect.
Si le schéma définit clairement un <xs:sequence>, alors l'ordre des éléments est important. Un XML avec les bons éléments mais dans le mauvais ordre sera considéré comme invalide.
Erreur n°4 : le XML utilise plusieurs namespaces.
Si le document utilise plus d'un namespace, cela peut causer des échecs inattendus dans la validation. Gérer plusieurs namespaces demande une attention particulière et une configuration précise des schémas.
Erreur n°5 : on ne collecte pas et ne conserve pas les erreurs.
Afficher les erreurs dans la console peut aller pour le debug, mais pas pour une application en production. Mieux vaut collecter les erreurs dans une liste et les présenter à l'utilisateur de façon claire — surtout quand on vérifie beaucoup de fichiers (par exemple sur un serveur web).
GO TO FULL VERSION