XML Schema Definition

XML Schema ist eine Empfehlung des W3C zum Definieren von Strukturen für XML-Dokumente. Anders als bei den klassischen XML-DTDs wird die Struktur in Form eines XML-Dokuments beschrieben. Darüber hinaus wird eine große Anzahl von Datentypen unterstützt.

Einleitung

XML-Schema beschreibt in einer komplexen Schemasprache Datentypen, einzelne XML-Schema-Instanzen (Dokumente) und Gruppen solcher Instanzen. Ein konkretes XML-Schema wird auch als eine XSD (XML-Schema-Definition) bezeichnet und hat als Datei üblicherweise die Endung ".xsd". Im Gegensatz zu DTDs kann bei Verwendung von XML-Schemas zwischen dem Namen des XML-Typs und dem in der Instanz verwendeten Namen des XML-Tags unterschieden werden.

Außer XML-Schemata sind weitere Konzepte zur Definition von XML-Strukturen mit verschiedenen Intentionen bekannt, wie DTD, RELAX NG oder Schematron.

Datentypen

XML Schema unterscheidet zwischen einfachen (atomaren) Datentypen und komplexen Datentypen. Der Begriff Typ bezeichnet im nachfolgenden Text jeweils die abstrakte Spezifikation der Struktur eines Abschnitts innerhalb eines XML-Dokumentes. Datentypen in XML Schema werden klassifiziert in eingebaute bzw. vordefinierte (built-in) und benutzerdefinierte (user defined) Datentypen.

In der Spezifikation des W3C für XML-Schema sind 19 voreingestellte primitive Datentypen (z.B. boolean, string, float, date und NOTATION) und weitere 25 davon abgeleitete primitive Datentypen (wie ID und integer) definiert.

Einfache Typen

XML Schema stellt einige grundlegende atomare Datentypen bereit. Die atomaren Datentypen enthalten die „klassischen“ Typen, wie sie zum Teil auch in anderen Typsystemen (z. B. C, Java oder SQL) spezifiziert sind:

• xsd:string
• xsd:decimal
• xsd:integer
• xsd:float
• xsd:boolean
• xsd:date
• xsd:time

Hinzu kommen weitere XML-spezifische atomare Typen, unter anderem:

• QName: Qualified Name, global eindeutiger Bezeichner. Aufgebaut aus sog. NCNames (Non-Colonized Names), wobei jeder NCName bis auf den letzten einen Namensraum ("Namespace") bezeichnet. Der letzte NCName entspricht dem lokalen Namen innerhalb des Namensraumes. Die einzelnen NCNames werden mittels Punkt (.) zu einem QName zusammengesetzt.
• anyURI: Uniform Resource Identifier (URI)
• language: Sprachbezeichnung, z. B. de-DE, en-US, fr
• ID: Identifikationsattribut innerhalb von XML-Elementen
• IDREF: Referenz auf einen ID-Wert

Einfache XML-Datentypen dürfen weder XML-Kindelemente enthalten noch XML-Attribute besitzen.

Außer den atomaren Datentypen gehören Listen und Unions (bestehend aus atomaren Elementen) zu den einfachen Typen:

• Das folgende Beispiel definiert einen neuen XML-Datentyp mit dem Namen monatInt sowie eine Liste dieses neuen Typs:

<xsd:simpleType name="monatInt">
  <xsd:restriction base="xsd:integer">
    <xsd:minInclusive value="1"/>
    <xsd:maxInclusive value="12"/>
  </xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="monate">
  <xsd:list itemType="monatInt"/>
</xsd:simpleType>

Eine Instanz des neuen Typs könnte wie folgt aussehen:

<monate>
   1 2 3 4 5 6 7 8 9 10 11 12
</monate>

Die einzelnen Elemente einer Liste werden durch Leerzeichen getrennt.

• Zu den einfachen Typen gehören zusätzlich noch sogenannte Vereinigungen (engl. unions).

Ein neuer Typ wird als Vereinigung bereits bestehender Typen definiert. Das nachfolgende Beispiel definiert einen weiteren Typ monatsname sowie einen Union Typ monat:

<xsd:simpleType name="monatsname">
  <xsd:restriction base="xsd:string">
    <xsd:enumeration value="Jan"/>
    <xsd:enumeration value="Feb"/>
    <xsd:enumeration value="Mär"/>
    <!-- und so weiter ... -->
  </xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="monat">
  <xsd:union memberTypes="monatsname monatInt"/>
</xsd:simpleType>

XML-Elemente vom Typ monat dürfen sowohl Integer Werte im Bereich 1–12 enthalten als auch eine der entsprechenden Monatsbezeichnungen als Zeichenkette.

Komplexe Typen

In Ergänzung zu den einfachen Typen bieten komplexe XML-Datentypdefinitionen die Möglichkeit, Elementenstrukturen zusammenhängend zu definieren. Solche Strukturen können weitere Elemente und Attribute beinhalten.

Das folgende Beispiel definiert einen neuen Typ pc-Typ mit entsprechenden Kindelementen name, hersteller etc., sowie einem Attribut id:

<xsd:complexType name="pc-Typ">
  <xsd:sequence>
    <xsd:element name="name"       type="xsd:string"/>
    <xsd:element name="hersteller" type="xsd:string"/>
    <xsd:element name="prozessor"  type="xsd:string"/>
    <xsd:element name="mhz"        type="xsd:integer" minOccurs="0"/>
    <xsd:element name="kommentar"  type="xsd:string"  minOccurs="0" maxOccurs="unbounded"/>
  </xsd:sequence>
  <xsd:attribute name="id" type="xsd:integer"/>
</xsd:complexType>

Die Möglichkeiten zur Definition komplexer Typen sollen hier nur exemplarisch erläutert werden. Der interessierte Leser sei auf die unten angegebenen Links zu den Seiten des W3C verwiesen.

Die Kindelemente eines komplexen Typs können auf drei unterschiedliche Arten kombiniert werden:

• xsd:sequence: Eine Liste von Kindelementen wird spezifiziert. Jedes dieser Elemente kann keinmal, einmal oder mehrfach auftreten (Attribute minOccurs und maxOccurs). Falls kein occurs-Attribut vorhanden ist, wird in beiden Fällen der Default-Wert 1 verwendet. Die Elemente innerhalb einer sequence müssen in der angegebenen Reihenfolge auftreten. In dem oben gezeigten Beispiel müssen die Elemente name, hersteller und prozessor genau einmal auftreten, das mhz-Element kann null- oder einmal auftreten, kommentar-Elemente können beliebig oft oder auch gar nicht auftreten.
• xsd:choice: Aus einer Liste von Alternativen kann ein Element ausgewählt werden. Das nachfolgende Beispiel definiert einen neuen Typ computer, der als Kindelement entweder ein desktop-Element besitzt (vom Typ pc-Type) oder ein laptop-Element:

<xsd:complexType name="computer">
  <xsd:choice>
    <xsd:element name="desktop" type="pc-Typ"/>
    <xsd:element name="laptop" type="laptop-Typ"/>
  </xsd:choice>
</xsd:complexType>

• xsd:all: Mittels des xsd:all-Tags lässt sich eine Gruppe von Kindelementen definieren, von denen jedes maximal einmal auftreten darf (min- und maxOccurs der Kindelemente dürfen nur die Werte 0 oder 1 annehmen). Die Reihenfolge der Elemente ist beliebig.

Beliebiger Inhalt

XML-Elemente mit beliebigem Inhalt lassen sich mittels des Basistyps anyType definieren. Der nachfolgende Code spezifiziert ein kommentar-Element beliebigen Inhalts, d. h. sowohl komplexe XML-Elemente als auch Text können vorkommen.

<xsd:element name="kommentar" type="xsd:anyType"/>

Sollen in dem Inhalt Text und Tags in beliebiger Reihenfolge vorkommen können, muss der Wert für das Attribut "mixed" auf "true" gesetzt werden:

<xsd:element name="tagname" mixed="true"/>

Listen

Ein Element kann eine "Liste" von einfachen Daten enthalten:

<xsd:element name="intvalues" type="intlist"/>
 
<xsd:simpleType name="intlist">
    <xsd:list itemType="xsd:integer"/>
</xsd:simpleType>

Das Trennzeichen (das Zeichen, das die Einträge der Liste trennt) ist das Leerzeichen:

<intvalues>1 2 3</intvalues>

Leere Elemente

Von leeren XML-Elementen spricht man, wenn das jeweilige Element aus nur einem einzelnen XML-Tag besteht und keine weiteren XML-Elemente oder Text umschließt (z. B. der XHTML-Zeilenumbruch: <br />). XML Schema bedient sich an dieser Stelle eines kleinen Tricks: Es wird mittels xsd:complexType ein neuer Typ definiert, ohne ein Kindelement anzugeben. Da xsd:complexType nach Vorgabe nur komplexe XML-Kindelemente als Inhalt zulässt, bleibt das jeweilige Element in diesem Fall leer.

Ableitung neuer Typen

Neue Datentypen lassen sich zum einen durch die Definition eines neuen Typs erstellen (siehe vorheriger Abschnitt) oder durch die Ableitung eines neuen Typs aus bereits bestehenden. Die Ableitung eines neuen Typs kann auf zweierlei Arten erfolgen: Erweiterung oder Einschränkung.

Erweiterung eines Typs

Die Erweiterung eines bisherigen Typs (engl. extension) um weitere Eigenschaften, d. h. neue Elemente oder Attribute werden hinzugefügt. Im folgenden Beispiel wird der oben definierte Typ pc-Typ um ein Element ram erweitert:

<xsd:complexType name="myPC-Typ">
  <xsd:complexContent>
    <xsd:extension base="pc-Typ">
      <xsd:sequence>
        <xsd:element name="ram" type="xsd:integer"/>
      </xsd:sequence>
    </xsd:extension>
  </xsd:complexContent>
</xsd:complexType>

Der neu definierte XML-Typ myPC-Typ besteht aus allen Kindelementen des Typs pc-Typ sowie dem Element ram. Letzteres wird, wie in einer xsd:sequence-Definition, an die bisherigen Kindelemente angehängt.
Die Erweiterung einer bestehenden Typdefinition impliziert jedoch keine Substituierbarkeit, d. h. an einer Stelle an der ein Element vom Typ pc-Typ erwartet wird, darf nicht ohne weiteres ein Element vom Typ myPC-Typ verwendet werden (Casts sind jedoch möglich).

Einschränkung eines Typs

Durch Einschränkung bereits bestehender Typen (engl. restriction) lassen sich ebenfalls neue Definitionen ableiten. Zu diesem Zweck müssen alle Elementdefinitionen des Basistyps wiederholt werden, verändert um die jeweiligen restriktiveren Einschränkungen. Im folgenden Beispiel wird ein neuer Typ myPC2-Typ von pc-Typ abgeleitet. In diesem Fall darf maximal ein kommentar-Element auftreten (im Gegensatz zu einer beliebigen Anzahl beim Typ pc-Typ)

<xsd:complexType name="myPC2-Typ">
  <xsd:complexContent>
    <xsd:restriction base="pc-Typ">
      <xsd:sequence>
       <xsd:element name="name"       type="xsd:string"/>
       <xsd:element name="hersteller" type="xsd:string"/>
       <xsd:element name="prozessor"  type="xsd:string"/>
       <xsd:element name="mhz"        type="xsd:integer" minOccurs="0"/>
       <xsd:element name="kommentar"  type="xsd:string" minOccurs="0" maxOccurs="1"/>
      </xsd:sequence>
    </xsd:restriction>
  </xsd:complexContent>
</xsd:complexType>

Zusätzlich zu der Einschränkung komplexer Typen ist es auch möglich, neue Typen als Einschränkung einfacher Typen zu definieren. Ein Beispiel für eine solche Definition befindet sich bereits im Abschnitt zu den einfachen Typen. Ein neuer Typ monatInt wird als Einschränkung des Typs Integer auf den Wertebereich 1–12 definiert. Grundsätzlich stehen die folgenden Primitive zur Verfügung, um Einschränkungen auf einfachen Typen zu beschreiben:

• length, maxLength, minLength – Beschränkt die Länge eines Strings oder einer Liste.
• enumeration – Beschränkung durch Angabe alternativer Werte
• pattern – Beschränkung durch Angabe eines regulären Ausdrucks
• minExclusive, minInclusive, maxExclusive, maxInclusive – Einschränkung des Wertebereichs.
• totalDigits, fractionDigits – Einschränkung der Dezimalstellen (Gesamtzahl und Nachkommastellen)
• whiteSpace – Behandlung von Leerzeichen und Tabs

Die folgenden Beispiele veranschaulichen die Verwendung dieser Komponenten:

• Körpertemperatur, 3 Dezimalstellen, 1 Nachkommastelle, Minimal- und Maximalwert

<xsd:simpleType name="celsiusKörperTemp">
  <xsd:restriction base="xsd:decimal">
    <xsd:totalDigits value="3"/>
    <xsd:fractionDigits value="1"/>
    <xsd:minInclusive value="35.0"/>
    <xsd:maxInclusive value="42.5"/>
  </xsd:restriction>
</xsd:simpleType>

• Deutsche Postleitzahlen, optionales „D “ gefolgt von fünf Ziffern

<xsd:simpleType name="plz">
   <xsd:restriction base="xsd:string">
     <xsd:pattern value="(D )?[0-9]{5}"/>
   </xsd:restriction>
</xsd:simpleType>

• Größenangabe

<xsd:simpleType name="size">
  <xsd:restriction base="xsd:string">
    <xsd:enumeration value="XS"/>
    <xsd:enumeration value="S"/>
    <xsd:enumeration value="M"/>
    <xsd:enumeration value="L"/>
    <xsd:enumeration value="XL"/>
  </xsd:restriction>
</xsd:simpleType>

Bei der Definition eines Typs ist es möglich festzulegen, ob und auf welche Art von diesem Typ weitere XML-Elementtypen abgeleitet werden dürfen. So kann man zum Beispiel festlegen, dass von einem Typ pc-Typ weitere Typen nur durch das Setzen weiterer Einschränkungen abgeleitet werden dürfen – und nicht durch das Hinzufügen neuer Kindelemente.

Elementdefinition

Wie im vorangegangenen Abschnitt erläutert, erlaubt es XML Schema neue XML-Datentypen zu definieren und diese bei der Definition eigener XML-Elemente zu verwenden. Das folgende Beispiel veranschaulicht die Verwendung des bereits definierten Types pc-Typ innerhalb einer Liste von pc-Elementen:

<xsd:element name="pc-liste">
  <xsd:complexType>
    <xsd:sequence>
      <xsd:element name="pc" type="pc-Typ" maxOccurs="unbounded"/>
    </xsd:sequence>
  </xsd:complexType>
</xsd:element>

Ein entsprechendes XML-Element könnte wie folgt aussehen:

<pc-liste>
  <pc>
    <name>Dimension 3100 </name>
    <hersteller>Dell</hersteller>
    <prozessor>AMD</prozessor>
    <mhz>3060</mhz>
    <kommentar>Arbeitsplatzrechner</kommentar>
  </pc>
  <pc>
    <name>T 42</name>
    <hersteller>IBM</hersteller>
    <prozessor>Intel</prozessor>
    <mhz>1600</mhz>
    <kommentar>Laptop</kommentar>
  </pc>
</pc-liste>

Innerhalb dieses Beispiels erfolgt die Spezifikation des anonymen Listentyps direkt innerhalb der Elementdefinition, während die Spezifikation des pc-Typs extern erfolgt.

Bei dem Entwurf eines komplexen XML-Schemas sollte sowohl die Wiederverwendbarkeit und Erweiterbarkeit der einzelnen XML-Elementtypen als auch die Lesbarkeit des Schemas selbst berücksichtigt werden. Die Verwendung anonymer XML-Elementtypen als Teil größerer Elemente gewährleistet im Allgemeinen eine bessere Lesbarkeit kleinerer XML-Schemata. Die Definition und Benennung einzelner, kleinerer und wiederverwendbarer XML-Elementtypen hingegen ermöglicht eine stärkere Modularisierung der XML-Schema-Struktur. Aufgrund der Vielzahl möglicher Anwendungsszenarien haben sich bisher noch keine allgemeingültigen Entwurfprinzipien für XML-Schemata herausgebildet (vergleichbar den Normalformen für relationale Datenbanken).

Weiterführende Konzepte und Eigenschaften

Eindeutige Schlüssel

Vergleichbar den Primärschlüsseln in relationalen Datenbanken lassen sich mittels XML Schema eindeutige Schlüssel definieren. XML Schema unterscheidet zwischen der Eindeutigkeit (engl. unique) und der Schlüsseleigenschaft.

Das nachfolgende Beispiel definiert ein neues Element pc-list mit einer Liste von pc-Kindelementen:

<xsd:element name="pc-list">
  <xsd:complexType>
    <xsd:sequence>
      <xsd:element name="computer" type="pc-Typ" maxOccurs="unbounded"/>
    </xsd:sequence>
  </xsd:complexType>
  <xsd:unique name="her-name">
    <xsd:selector xpath="computer"/>
    <xsd:field xpath="name"/>
    <xsd:field xpath="hersteller"/>
  </xsd:unique> 
  <xsd:key name="idKey">
    <xsd:selector xpath="computer"/>
    <xsd:field xpath="@id"/>
  </xsd:key>
</xsd:element>

Die beiden Elemente unique und key selektieren mit einem XPath Pfadausdruck (im Beispiel: computer) eine Menge von computer-Elementen. Für diese Menge muss die jeweilige Eindeutigkeits- bzw. Schlüsselbedingung erfüllt werden. Im obigen Beispiel wird festgelegt, dass die Kombination der Elemente name und hersteller für jedes computer-Element innerhalb dieser Liste eindeutig sein muss.
Durch das key-Element wird festgelegt, dass das Attribut id innerhalb dieser Liste eindeutig sein muss und von außerhalb referenziert werden kann.

Das folgende Beispiel zeigt die Referenzierung dieses Schlüssels mit dem Attribut refer und dem Schlüsselwort @references.

<xsd:keyref name="idFremdKey" refer="idKey">
  <!-- idKey von obigem Beispiel -->
  <xsd:selector xpath="computerFremd"/>
  <xsd:field xpath="@references"/>
</xsd:keyref>

Beachte

Mit refer bezieht man sich auf das name-Attribut einer Schlüsselbedingung, nicht auf das Schlüsselfeld. Die Werte in references müssen also immer unter den Schlüsseln zu den computern zu finden sein. (Hintergrund dieses Konstrukts ist die Sicherstellung der referentiellen Integrität, wie man sie von relationalen Datenbanksystemen her kennt.)

Import, Include und Redefine

XML Schema erlaubt es, fremde Schemata wiederzuverwenden.
Hierzu stehen sowohl der include- als auch der import-Tag zur Verfügung sowie die Möglichkeit einer neuen Definition bzw. Anpassung fremder Schemata beim Einbinden.

include

Typdefinitionen innerhalb eines Namensraumes, die auf mehrere Dateien verteilt sind, lassen sich mittels include zusammenfügen.

<schema xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:pcTeile="http://www.example.com/pcTeile"
        targetNamespace="http://www.example.com/pcTeile">
  ...
  <include schemaLocation="http://www.example.com/schemata/harddisk.xsd"/>
  <include schemaLocation="http://www.example.com/schemata/ram.xsd"/>
  ...
</schema>

• mehrere Schemata können inkludiert werden.
• targetNamespace des harddisk.xsd muss mit dem des inkludierenden Schemas übereinstimmen.

redefine

Gleiches Beispiel wie gerade. Annahme es gäbe einen complexType Hersteller im Schema harddisk.xsd.

<schema xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:pcTeile="http://www.example.com/pcTeile"
        targetNamespace="http://www.example.com/pcTeile">
  ...
  <redefine schemaLocation="http://www.example.com/schemata/harddisk.xsd">
    <!-- redefinition of Hersteller -->
    <complexType name="Hersteller">
      <complexContent>
        <!-- redefinition of Hersteller mit ''restriction'' oder auch ''extension'' etc. -->
        <restriction base="pcTeile:Hersteller">
          <sequence>
            <element name="hersteller" type="string" minOccurs="10" maxOccurs="10"/>
          </sequence>
        </restriction>
      </complexContent>
    </complexType>
  </redefine>
  ...
  <include schemaLocation="http://www.example.com/schemata/ram.xsd"/>
  ...
</schema>

• redefine kann an Stelle von include verwendet werden.
• Der Name des Typs ändert sich dabei nicht.

import

Der import-Tag erlaubt es, Elemente aus anderen Namensräumen zu importieren, mit einem Präfix zu versehen und damit Schema-Bestandteile aus unterschiedlichen Namensräumen wiederzuverwenden.
Annahme ist, dass es einen definierten Typ superTyp in pcTeile gibt.

<schema xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:pcTeile="http://www.example.com/pcTeile"
        targetNamespace="http://www.example.com/firma">
  ...
  <import namespace="http://www.example.com/pcTeile"/>
  ...
    <...
      <xsd:attribute name="xyz" type="pcTeile:superTyp"/>
    .../>
  ...
</schema>

Verwendung von XML-Schemata

Zur Verwendung eines XML-Schemas in einer XML-Datei muss das Attribut schemaLocation des Schema-Instance-Namensraums verwendet werden, um ein gewünschtes Schema einem Namensraum zuzuweisen. In folgendem Beispiel wird ausgedrückt, dass der Standard-Namensraum http://www.w3.org/1999/xhtml ist und dann angegeben, dass das XML-Schema für diesen Namensraum unter http://www.w3.org/1999/xhtml.xsd aufzufinden ist.

<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://www.w3.org/1999/xhtml
                          http://www.w3.org/1999/xhtml.xsd">

Die Definition gilt für das XML-Element, bei dem die Attribute angegeben sind, und alle Kinderelemente.

Ist im XML-Dokument kein Namensraum definiert, muss das Attribut noNamespaceSchemaLocation verwendet werden:

<html xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:noNamespaceSchemaLocation="http://www.w3.org/1999/xhtml.xsd">

Beispiel

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <xsd:element name="html">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element ref="head"/>
        <xsd:element name="body" type="xsd:string"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>
  <xsd:element name="head">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="title" type="xsd:string"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>
</xsd:schema>

Dies entspricht abgesehen vom Namensraum folgender DTD

<!ELEMENT html (head, body)>
<!ELEMENT head (title)>
<!ELEMENT title (#PCDATA)>
<!ELEMENT body (#PCDATA)>

Siehe auch

• Liste der XML-Namensräume
• RELAX NG
• WSDL
• Schematron
• Document Structure Description (DSD)

Literatur

• Alfons Kemper, André Eickler: Datenbank Systeme - Eine Einführung. Oldenbourg Wissenschaftsverlag, München 2004, ISBN 3486273922. 

Weblinks

• W3C XML Schema Specification: Primer, Structures, Datatypes, and Miscellaneous
• W3C XML-Schema-Spezifikation (deutsche Übersetzungen): Einführung, Strukturen, Datentypen
• W3 Schools: XML Schema Tutorial (englisch)
• XML Schema Validator online – Provided by DecisionSoft
• W3C Validator for XML Schema online
• XML Schema: deutsches Einführungsdokument (PDF, 186 kB, 20 Seiten)
• bitworld.de - XML, DTD und XML-Schema

Standards des World Wide Web Consortiums

Empfehlungen (recommendations): Canonical XML | CDF | CGI | CSS | DOM | HTML | MathML | OWL | PLS | RDF | RDF-Schema | SISR | SMIL | SOAP | SRGS | SSML | SVG | SPARQL | Timed Text | VoiceXML | WSDL | XForms | XHTML | XML | XML Base | XML Events | XML Information Set | XML Schema | XML Signature | XPath | XPointer | XQuery | XSL Transformation | XSL-FO | XSL | XLink

Anmerkungen (notes): XHTML+SMIL | XAdES

Arbeitsentwürfe (working drafts): CCXML | CURIE | InkML | XFrames | XFDL | WICD | XHTML+MathML+SVG | XBL | XProc | HTML 5