XML mit XSLT direkt im Browser prüfen

Wann XSLT eine praktische Alternative zu Schematron sein kann

Schematron gehört zu den nützlichsten Technologien, wenn Geschäftsregeln und semantische Bedingungen für XML-Dokumente formuliert werden sollen. Besonders stark ist Schematron dann, wenn Prüfregeln unabhängig von der Darstellung gepflegt werden sollen und standardisierte Validierungsberichte benötigt werden.

Aber nicht in jeder Umgebung stehen ein Schematron-Prozessor, ein XML-Editor, ein Kommandozeilenwerkzeug oder ein serverseitiger Prüfdienst zur Verfügung. In manchen Projekten ist die Anforderung deutlich einfacher: Ein Anwender soll ein XML-Dokument öffnen und unmittelbar eine verständliche Darstellung zusammen mit Prüfergebnissen erhalten.

Für genau solche Szenarien kann XSLT eine überraschend praktische Lösung sein.

Ein XML-Dokument kann über eine xml-stylesheet Processing Instruction auf ein XSLT-Stylesheet verweisen. Wird die XML-Datei in einem Browser mit integrierter XSLT-Unterstützung geöffnet, lädt der Browser das Stylesheet, transformiert die XML-Daten nach HTML und zeigt das Ergebnis an. Im selben Stylesheet können außerdem Prüfregeln enthalten sein, die Fehler, Warnungen und Hinweise direkt bei den Daten darstellen.

Damit entsteht aus XML und XSLT eine sehr leichtgewichtige Prüfanwendung.

Weitere Inhalte dieser Seite:

Die Grundidee
Ein fiktives Beispiel aus der Altersvorsorge
Warum XSLT statt Schematron?
Prüfung und Darstellung in einem Stylesheet
Fehler, Warnung und Information
Eine kleine Anwendung ohne Applikationsserver
Warum XSLT 1.0 hier wichtig ist
XSLT-Prüfung und Schematron sind keine Gegenspieler
Inhalt des herunterladbaren Beispiels
Fazit
Download der Beispieldateien

Die Grundidee

Das XML-Dokument enthält beispielsweise folgende Processing Instruction:

<?xml-stylesheet type="text/xsl" href="pension-check.xsl"?>

Der Browser führt anschließend automatisch vier Schritte aus:

1. Er öffnet das XML-Dokument.

2. Er liest die xml-stylesheet Processing Instruction.

3. Er lädt das referenzierte XSLT-Stylesheet.

4. Er transformiert das XML-Dokument in eine HTML-Seite.

Das XSLT muss sich dabei nicht auf die Darstellung beschränken. Es kann gleichzeitig Regeln auf den XML-Inhalt anwenden.

Zum Beispiel:

<xsl:if test="not(applicant/email) or not(contains(applicant/email, '@'))">
  <div class="message error">
    A valid email address is required.
  </div>
</xsl:if>

Die Regel wird während der Transformation ausgeführt. Ist die Bedingung erfüllt, enthält das erzeugte HTML eine entsprechende Fehlermeldung.

Darstellung und Prüfung erfolgen damit in einem Verarbeitungsschritt.

Ein fiktives Beispiel aus der Altersvorsorge

Für das herunterladbare Beispiel verwenden wir die vollständig fiktive Organisation Northbridge Pension Services. Das Beispiel übernimmt bewusst weder Erscheinungsbild noch Terminologie, Kennungen oder Datenmodelle einer realen Rentenversicherung.

Die XML-Datei enthält einen Antrag mit Daten wie:

• Vorgangsnummer

• Name der antragstellenden Person

• Geburtsdatum

• E-Mail-Adresse

• gewünschter Rentenbeginn

• Leistungsart

• Beitragszeiträume

• Anzahl der Beitragsmonate

Ein vereinfachter Ausschnitt sieht so aus:

<pensionClaim id="NB-2026-0042">
  <applicant>
    <firstName>Alex</firstName>
    <lastName>Johnson</lastName>
    <dateOfBirth>1965-04-12</dateOfBirth>
    <email>alex.johnson@example.org</email>
  </applicant>
  <requestedRetirementDate>2030-05-01</requestedRetirementDate>
  <pensionType>old-age</pensionType>
  <contributionHistory>
    <period from="1990-01" to="1999-12" type="employment" months="120"/>
    <period from="2000-01" to="2010-12" type="self-employed" months="132"/>
    <period from="2011-01" to="2020-12" type="employment" months="120"/>
  </contributionHistory>
</pensionClaim>

Das Stylesheet kann unter anderem folgende Regeln prüfen:

• Ist eine Vorgangsnummer vorhanden?

• Sind Vorname und Nachname vorhanden?

• Enthält die E-Mail-Adresse ein @-Zeichen?

• Liegt der gewünschte Rentenbeginn nach dem Geburtsdatum?

• Sind Beitragszeiträume vollständig?

• Gibt es auffällige Lücken zwischen Beitragszeiträumen?

• Liegt der gewünschte Rentenbeginn ungewöhnlich weit in der Zukunft?

In der Browseransicht können die Ergebnisse anschließend in erfolgreiche Prüfungen, Warnungen und Fehler gruppiert werden.

Warum XSLT statt Schematron?

Es geht nicht darum, Schematron grundsätzlich zu ersetzen. Beide Technologien lösen unterschiedliche Aufgaben und können sich sehr gut ergänzen.

Schematron ist normalerweise die bessere Wahl, wenn die Validierung ein formaler Teil einer Verarbeitungskette ist, Regeln zwischen verschiedenen Systemen austauschbar bleiben sollen, SVRL benötigt wird oder die Prüfung bewusst unabhängig von der Darstellung erfolgen soll.

XSLT wird besonders interessant, wenn eine unmittelbar nutzbare Browseransicht im Vordergrund steht und keine eigene Validierungsumgebung zur Verfügung steht.

Eine browserbasierte XSLT-Lösung bietet einige praktische Vorteile:

• Anwender benötigen keinen speziellen XML-Editor

• es wird kein separater Schematron-Prozessor benötigt

• Prüfmeldungen können für nichttechnische Anwender formuliert werden

• das XML bleibt die Quelldatei

• Darstellung und Prüfung können gemeinsam ausgeliefert werden

• das gesamte Beispiel kann aus wenigen XML-, XSLT-, CSS- und Bilddateien bestehen

Das eignet sich beispielsweise für Prototypen, interne Prüfabläufe, Datenübergaben, Demonstrationen, Offline-Pakete, Qualitätssicherungsbeispiele und Szenarien, in denen strukturierte Daten ohne Installation einer Spezialsoftware kontrolliert werden sollen.

Prüfung und Darstellung in einem Stylesheet

Ein Stylesheet kann zunächst Prüfzustände ermitteln und anschließend sowohl die Nutzdaten als auch die Meldungen darstellen.

Beispiel:

<xsl:variable name="emailValid"
              select="contains(applicant/email, '@')"/>

<xsl:choose>
  <xsl:when test="$emailValid">
    <div class="check passed">Email address looks valid.</div>
  </xsl:when>
  <xsl:otherwise>
    <div class="check error">Email address is invalid.</div>
  </xsl:otherwise>
</xsl:choose>

Das gleiche Stylesheet kann oben eine Zusammenfassung und weiter unten detaillierte Prüfergebnisse erzeugen.

Der Anwender sieht damit Inhalt und Prüfstatus in einer einzigen Oberfläche.

Fehler, Warnung und Information

Nicht jede Regelverletzung muss eine Verarbeitung stoppen. Für eine verständliche Oberfläche ist eine Unterscheidung verschiedener Meldungstypen sinnvoll.

Fehler

Ein Fehler bedeutet, dass Daten unvollständig oder widersprüchlich sind und normalerweise korrigiert werden sollten.

Beispiel:

The requested retirement date must be after the applicant's date of birth.

Warnung

Eine Warnung kennzeichnet einen auffälligen Zustand, der durchaus zulässig sein kann, aber geprüft werden sollte.

Beispiel:

Contribution history contains an unexplained gap of more than 24 months.

Information

Eine Informationsmeldung bestätigt eine Bedingung oder liefert zusätzlichen Kontext.

Beispiel:

All required personal data is present.

Entscheidend ist: Diese Meldungen werden unmittelbar aus den XML-Daten erzeugt. Der Anwender muss keine XPath-Ausdrücke oder technischen Prüfberichte lesen.

Eine kleine Anwendung ohne Applikationsserver

Aus Sicht des Anwenders kann der Ablauf sehr einfach sein:

1. XML-Datei und Stylesheet erhalten.

2. XML-Datei in einem unterstützten Browser öffnen, bei Chrome und Edge in der Regel über den mitgelieferten lokalen Server-Starter.

3. Formatierte Daten und Prüfergebnisse kontrollieren.

Eine eigene Schematron-Anwendung ist dafür nicht erforderlich.

Das Browserverhalten muss trotzdem sorgfältig getestet werden. Die eingebauten XSLT-Prozessoren der Browser basieren üblicherweise auf XSLT 1.0. Außerdem können Sicherheitsregeln für lokale Dateien je nach Browser und Betriebssystem unterschiedlich ausfallen. In aktuellen Chrome- und Edge-Versionen darf ein direkt als file:// geöffnetes XML-Dokument die benachbarte XSLT-Datei nicht laden; das Beispiel stellt den Ordner deshalb über einen kleinen lokalen HTTP-Server bereit.

Das herunterladbare Beispiel sollte deshalb gegen die vorgesehenen Browser getestet und der unterstützte Ausführungsweg dokumentiert werden.

Warum XSLT 1.0 hier wichtig ist

Moderne XSLT-Prozessoren unterstützen XSLT 2.0 oder 3.0, XPath 3.1, reguläre Ausdrücke, fortgeschrittenes Gruppieren, Maps, Arrays und viele weitere Funktionen.

Der eingebaute XSLT-Prozessor eines Standardbrowsers stellt diesen modernen Funktionsumfang normalerweise nicht zur Verfügung. Ein reines Browserbeispiel sollte deshalb im tatsächlich unterstützten Bereich bleiben, typischerweise XSLT 1.0.

Das hat Auswirkungen auf die Prüfregeln. Komplexe Datumsberechnungen, schema-aware Processing, fortgeschrittene String-Verarbeitung und wiederverwendbare Validierungsframeworks lassen sich mit einem dedizierten Prozessor komfortabler umsetzen.

Das ist eine der wesentlichen Grenzen des Ansatzes.

XSLT-Prüfung und Schematron sind keine Gegenspieler

In Schematron wird eine Bedingung direkt als Assertion formuliert:

<sch:assert test="contains(email, '@')">
  A valid email address is required.
</sch:assert>

In XSLT wird die gleiche Idee prozedural umgesetzt:

<xsl:if test="not(contains(email, '@'))">
  <div class="error">A valid email address is required.</div>
</xsl:if>

Bei Schematron ist die Prüfregel selbst das zentrale Artefakt. Bei XSLT steht das erzeugte Ergebnis stärker im Mittelpunkt.

Diese Unterscheidung ist wichtig.

Schematron ist sinnvoll, wenn eine formale, wiederverwendbare Validierungsschicht benötigt wird. Browserbasiertes XSLT eignet sich, wenn ein in sich geschlossenes und unmittelbar lesbares Prüfwerkzeug wichtiger ist.

In größeren Systemen kann man selbstverständlich auch beides kombinieren: Schematron für die formale Validierung und XSLT für die Präsentation.

Inhalt des herunterladbaren Beispiels

Das ablauffähige Paket zu diesem Artikel enthält:

• pension-valid.xml

• pension-errors.xml

• pension-check.xsl

• eine kurze README-Datei mit Browserhinweisen

• start-demo.cmd und start-demo.ps1 als Windows-Ablaufpaket für Chrome und Edge

• Screenshots aus tatsächlich getesteten Browsern

Das Ablaufpaket startet über PowerShell einen kleinen lokalen HTTP-Server und öffnet die XML-Beispiele über localhost. Das ist für Chrome und Edge wichtig, weil deren Sicherheitsmodell die benachbarte XSLT-Datei blockiert, wenn das XML direkt aus dem Dateisystem geöffnet wird.

Das gültige Dokument zeigt einen sauberen Prüflauf. Das fehlerhafte Dokument löst bewusst mehrere unterschiedliche Meldungen aus.

Fazit

Schematron bleibt eine hervorragende Technologie für die semantische Prüfung von XML. Es ist aber nicht die einzige Möglichkeit, strukturierte XML-Daten zu kontrollieren.

Wenn eine leichtgewichtige Prüfansicht benötigt wird, die ein Anwender ohne spezielle XML-Validierungssoftware öffnen kann, lässt sich mit XSLT Prüfung und Darstellung sehr praktisch verbinden.

Das XML-Dokument referenziert das Stylesheet. Der Browser lädt das XSLT. Das Stylesheet kontrolliert die Daten und erzeugt daraus eine verständliche HTML-Oberfläche. Der Anwender sieht die Informationen zusammen mit den Prüfergebnissen, ohne eine spezielle XML-Validierungsanwendung installieren zu müssen.

Für das passende Szenario ist das kein Notbehelf, sondern eine bewusst einfache Architektur.

Download der Beispieldateien

Im Download-Ordner finden Sie alle Beispieldateien zu diesem Artikel.

<< zurück

vor >>