Aus Beispiel-XML entsteht ein XSD-Entwurf mit Attributen und einfachen Datentypen. Alle Vorkommen eines Elements werden zu einer Deklaration zusammengeführt; fremde Namespaces oder wechselnde Kindreihenfolgen erscheinen in den Befunden. Prüfen Sie das Schema, bevor Sie es einsetzen.
Läuft lokal in deinem BrowserFügen Sie ein repräsentatives XML-Dokument ein oder laden Sie mit Beispiel laden einen kleinen Katalog und drücken Sie dann XSD generieren. Das Werkzeug fasst alle Vorkommen eines Elements zu einer Deklaration zusammen und liefert ein Startschema, das Sie als inferred-schema.xsd kopieren oder herunterladen können.
Das Dokument wird vom XML-Parser des Browsers gelesen, deshalb liefert nur wohlgeformtes XML eine Ausgabe, und alles bleibt auf der Seite: kein Upload, kein Validierungsdienst, keine Anfrage an diese Website.
Werttypen folgen dem Text der Vorlage. Die Literale true und false werden xs:boolean; vorzeichenbehaftete Ganzzahlen wie 42, 0, 1, -7 oder 007 werden xs:integer; 3.5, .5 und 5. werden xs:decimal; 2026-08-29 und 2026-08-29T10:00:00Z werden xs:date und xs:dateTime. Alles andere — 0x1F, 1e3, TRUE — bleibt xs:string, weil diese Schreibweisen nicht zum lexikalischen Raum der genannten XSD-Typen gehören.
Die Kardinalität folgt den Vorkommen. Ein Kind, das sich innerhalb eines Elements wiederholt, erhält maxOccurs="unbounded"; ein Kind, das in mindestens einem Vorkommen seines Elternelements fehlt, erhält minOccurs="0". Die Vorkommen werden zusammengeführt statt stichprobenartig gelesen: Ein zweites tool-Element mit zusätzlichem Attribut oder Kind erweitert die Deklaration, und ein Element, das an einer Stelle leer und an einer anderen gefüllt erscheint, bleibt optional.
Zwei Formen ändern das Inhaltsmodell. Text zwischen Kindelementen erzeugt complexType mixed="true", und Kinder in wechselnder Reihenfolge — item, note, item — werden zu einem xs:choice maxOccurs="unbounded" statt zu einer Sequenz, weil eine Sequenz die eigene Vorlage ablehnen würde.
Trägt das Wurzelelement einen Namespace, wird er mit elementFormDefault="qualified" zum targetNamespace des erzeugten Schemas, sodass der Namespace der Vorlage erhalten bleibt. Die xmlns-Deklarationen selbst werden nie zu Attributen.
Elemente aus einem anderen Namespace lassen sich nicht im selben XSD-Dokument deklarieren. Sie werden als je ein xs:any-Platzhalter pro fremdem Namespace mit processContents="lax" ausgegeben, damit die Vorlage weiter validiert, und ein Befund hält den Kompromiss fest. Attribute mit Namespace wie xml:lang oder xsi:type lassen sich ebenfalls nicht namentlich deklarieren; der Typ akzeptiert sie über xs:anyAttribute.
Einfache Attribute werden ohne Namespace und als optional deklariert, mit denselben Werttyp-Regeln wie Elementtext, und alle Vorkommen eines Attributs werden wie Kindelemente zusammengeführt.
Die Seite kann das erzeugte Schema nicht gegen Ihr XML prüfen: Browser bringen keinen XSD-Validator mit. Kompilieren und testen Sie die Datei mit einem XSD-1.0-Prozessor — etwa xmllint --schema, lxml oder Saxon — und behalten Sie die Vorlage als Regressionstest. Ein Schema, das ein Dokument akzeptiert, kann für das nächste zu eng sein: ein Element, das hier zufällig optional war, oder ein Wert, der nur wie ein Datum aussah.
Beschrieben wird nur die Vorlage. Einschränkungen (xs:key, xs:unique, xs:length, Muster), Kommentare und Importe für weitere Namespaces werden weder abgeleitet noch erfunden; ergänzen Sie sie von Hand, wo sie zählen. Die Kardinalität ist eine Lesart dieses Dokuments, keine Spezifikation: Nichts hier besagt, dass ein Kind im Produktivverkehr auftreten muss.