Créez une ébauche de schéma XSD à partir d’un exemple XML, avec ses attributs et des types de données simples. Toutes les occurrences d’un élément sont fusionnées en une déclaration, et les espaces de noms étrangers ou un ordre instable des enfants apparaissent dans les signalements ; vérifiez le schéma avant de l’utiliser.
Fonctionne localement dans votre navigateurCollez un document XML représentatif, ou cliquez sur Charger un exemple pour un petit catalogue, puis sur Générer XSD. L’outil fusionne toutes les occurrences d’un élément en une seule déclaration et renvoie un schéma de départ que vous pouvez copier ou télécharger sous le nom inferred-schema.xsd.
Le document est analysé par l’analyseur XML du navigateur : seul un XML bien formé produit une sortie, et tout reste dans la page, sans envoi, sans service de validation et sans requête vers ce site.
Les types de valeur suivent le texte de l’échantillon. Les littéraux true et false deviennent xs:boolean ; les entiers signés comme 42, 0, 1, -7 ou 007 deviennent xs:integer ; 3.5, .5 et 5. deviennent xs:decimal ; 2026-08-29 et 2026-08-29T10:00:00Z deviennent xs:date et xs:dateTime. Tout le reste - 0x1F, 1e3, TRUE - reste xs:string, car ces graphies n’appartiennent pas à l’espace lexical des types XSD cités.
La cardinalité suit les occurrences. Un enfant qui se répète dans un élément reçoit maxOccurs="unbounded" ; un enfant absent d’au moins une occurrence de son parent reçoit minOccurs="0". Les occurrences sont fusionnées plutôt qu’échantillonnées : un second élément tool qui ajoute un attribut ou un enfant élargit la déclaration, et un élément vide à un endroit puis rempli ailleurs reste facultatif.
Deux formes modifient le modèle de contenu. Du texte autour d’éléments enfants produit complexType mixed="true", et des enfants répétés dans un ordre différent - item, note, item - deviennent un xs:choice maxOccurs="unbounded" au lieu d’une séquence, car une séquence rejetterait l’échantillon qui l’a produite.
Quand l’élément racine porte un espace de noms, celui-ci devient le targetNamespace du schéma généré avec elementFormDefault="qualified" : l’espace de noms de l’échantillon est donc conservé. Les déclarations xmlns ne deviennent jamais des attributs.
Les éléments d’un autre espace de noms ne peuvent pas être déclarés dans le même document XSD. Ils sortent sous forme d’un joker xs:any par espace de noms étranger avec processContents="lax", l’échantillon reste donc valide, et un signalement documente le compromis. Les attributs avec espace de noms, comme xml:lang ou xsi:type, ne peuvent pas non plus être déclarés par leur nom ; le type les accepte via xs:anyAttribute.
Les attributs simples sont déclarés sans espace de noms et facultatifs, avec les mêmes règles de type que le texte des éléments, et toutes les occurrences d’un attribut sont fusionnées comme les éléments enfants.
La page ne peut pas vérifier le schéma généré contre votre XML : les navigateurs n’embarquent pas de validateur XSD. Compilez et testez le fichier avec un processeur XSD 1.0 - par exemple xmllint --schema, lxml ou Saxon - et gardez l’échantillon comme cas de régression. Un schéma qui accepte un document peut rester trop étroit pour le suivant : un élément devenu facultatif ici, ou une valeur qui ressemblait seulement à une date.
Seul l’échantillon est décrit. Les contraintes (xs:key, xs:unique, xs:length, motifs), les commentaires et les imports pour d’autres espaces de noms ne sont ni déduits ni inventés ; ajoutez-les à la main là où ils comptent. La cardinalité est une lecture de ce document, pas une spécification : rien ici n’affirme qu’un enfant doit apparaître en production.