Genau genommen handelt es sich bei XML nicht um eine Auszeichnungssprache, sondern um eine Metasprache, mit deren Hilfe Markup-Sprachen definiert werden können. Diese werden als XML-Anwendungen bezeichnet und legen ein Vokabular und eine Grammatik fest, die die Struktur der darauf aufbauenden Dokumente bestimmen. Vermittelt über einschlägige Tools wie zum Beispiel Editoren, geben sie Autoren Regeln vor, in welchem Kontext welche Elemente verfügbar sind oder gar genutzt werden müssen. So könnte etwa eine Grammatik für eine technische Dokumentation verlangen, dass im Kopf eines Textes Angaben über den Verfasser stehen müssen, Kapitelelemente hingegen nicht dort, sondern nur im Textkörper verwendet werden dürfen.

In der Praxis zwingen XML-Anwendungen die Verfasser von Dokumenten aber meist nicht in ein allzu enges Korsett. Vielmehr sieht die XML-Spezifikation sogar vor, dass die Struktur von Texten mit Markup beschrieben werden kann, ohne dass ihnen überhaupt eine derartige Grammatik zu Grunde liegt. Sie müssen nur den syntaktischen Vorgaben von XML entsprechen. Sie gelten dann als "wohlgeformt", während jene, deren Übereinstimmung mit einer Grammatik überprüft wurde, als "valide" bezeichnet werden.

Wesentlich strenger als beim Verfassen von Dokumenten sind indes die Anforderungen an XML-Daten, wenn diese für den automatischen Informationsaustausch zwischen Applikationen genutzt werden. Bei Transaktionen, die durch XML-basierte Protokolle angestoßen werden, führen unter Umständen schon kleine Ungereimtheiten in den übertragenen Informationen zum Fehlschlagen der Operation. Allerdings reicht es nicht aus, dass Entwickler mittels Grammatiken die benutzten Datenformate möglichst genau festlegen. Vielmehr stoßen sie bei solchen Anwendungen an die Grenzen von XML und benötigen deshalb zusätzliche Möglichkeiten, um die Struktur von XML-Daten zu beschreiben.

Die Defizite von XML bei der Definition von Datenformaten, die Programme automatisch weiterverarbeiten sollen, entspringen den Eigenheiten der Document Type Definition (DTD). Sie stellt bis dato den einzigen standardisierten Mechanismus dar, um Grammatiken und Vokabulare für eine bestimmte Klasse von Dokumenten zu beschreiben. Dieses Verfahren geht auf die Standard Generalized Markup Language (SGML) zurück, von der XML insgesamt abgeleitet wurde. Entsprechend sind DTDs durch die Anforderungen geprägt, wie sie in Dokumentenumgebungen üblich sind.

Als ein besonderer Mangel bei allen Formen des Datenaustausches gilt, dass in DTDs Elementen oder Attributen keine Datentypen zugeordnet werden können, wie man sie von Programmiersprachen wie C oder Java her kennt. Offensichtlich führt dies zu Problemen, wenn beispielsweise die Replikation zwischen Datenbanken unterschiedlicher Hersteller über XML erfolgen soll. In diesem Fall könnte ein Datensatz, der übertragen wer-den soll, in ein Element namens "record" gepackt werden. Darin eingebettet, würden die einzelnen Feldwerte dann durch Elemente beschrieben, die dem Anwender Auskunft über die Feldnamen geben.

Allerdings könnten beim Einspeisen in die empfangende Datenbank Schwierigkeiten auftreten, wenn das XML-Element "Telefonnummer" an der Quelle eine Zeichenkette (String) auszeichnet, am Ziel aber ein numerischer Wert erwartet wird. Eine Validierung gegen eine DTD könnte den unerwünschten Versand von Zeichenketten aber nicht verhindern.

Die Kritik richtet sich auch aus anderen Gründen gegen DTDs. So erfolgt dort die Definition eines Dokumententyps in einer eigenen Syntax und nicht in jener von XML. Für XML-Entwickler bedeutet dies zusätzlichen Lernaufwand, außerdem wird dadurch die Programmierung von Tools aufwändiger. So müssen validierende Parser sowohl DTDs als auch XML-Dokumente verarbeiten können.

Weitere Kritikpunkte betreffen die geringe Kompatibilität mit dem Namespace-Standard sowie Einschränkungen, wenn die Reihenfolge oder Anzahl von Kindelementen festgelegt werden soll. Namespaces erlauben die Verwendung von Elementen aus mehreren Vokabularen innerhalb eines Dokuments. Wenn zwei Vokabulare zufällig ein Element gleichen Namens definieren, so können diese in einem Dokument anhand eines Namespace-Präfixes eindeutig zugeordnet werden. Bei gemischtem Inhalt (aus Elementen und PCDATA) können in DTDs die Anzahl und die Reihenfolge von Kindknoten nicht festgelegt werden. Auch hier ist einsichtig, dass bei XML-Daten, die Applikationen als Input dienen, die Reihenfolge der eintreffenden Informationen von Bedeutung sein kann.

All diese Schwächen sollen nach Vorstellung des W3-Consortiums XML-Schemata beseitigen. Wie bisher DTDs legen sie fest, wie Dokumente ausszusehen haben, die sich als Instanz dieses Dokumenttyps verstehen. Die Beschreibung des Vokabulars und seiner Verwendungsregeln erfolgt aber in XML-Syntax. Erwartungsgemäß legt die Schemaspezifikation eine ganze Reihe von Datentypen fest und erlaubt deren eindeutige Zuordnung zu Elementen. Für Fälle, wo diese nicht ausreichen, können Entwickler mit regulären Ausdrücken das Aussehen zulässiger Daten genau einschränken. Die Implementierung regulärer Ausdrücke orientiert sich an Perl und erlaubt beispielsweise, Währungsformate zu definieren. Die Häufigkeit, mit der bestimmte Elemente auftreten dürfen, kann mit den Attributen "minOccurs" und "maxOccurs" genau festgelegt werden. Zudem lässt sich über das "sequence"-Element die exakte Reihenfolge von Knoten vorschreiben.

XML Schema gilt als kompliziertNachdem Schemata die meisten Mängel von DTDs ausräumen, könnte man annehmen, dass Dokumenttypen in Zukunft vorwiegend damit beschrieben werden. Immerhin erlangte XML Schema Ende Oktober den Status einer Candidate Recommendation, die Verabschiedung als W3C-Empfehlung wird für das erste Quartal nächsten Jahres erwartet. Der Erfolg dieser Schemaspezifikation ist damit aber noch keineswegs gewiss. Zum einen liegt dies daran, dass sie von vielen Beobachtern als zu umfangreich und zu kompliziert empfunden wird. In einer Umfrage (http://www.ibiblio.org/xql/tally.html), die Jonathan Robie von der Software AG organisierte, äußerte die Hälfte der befragten XML-Entwickler, XML Schema enthalte Features, die sie wahrscheinlich nie benutzen werden. Dies spiegelt die Stimmung großer Teile der XML-Gemeinde auch in Hinblick auf andere Co-Standards wider. Wesentliche Ziele bei der Entwicklung von XML waren Einfachheit und Überschaubarkeit, die insbesondere durch Reduktion von SGML-Komplexität erreicht wurde. Während der XML-Kernstandard tatsächlich überschaubar ist, beläuft sich die Spezifikation von XML Schema ohne den Einführungsbeitrag auf mehr als 250 Druckseiten, der aktuelle Entwurf für XSL Formatting Objects geht sogar noch deutlich darüber hinaus.

Neben mangelnder Akzeptanz durch Entwickler könnte geringe Unterstützung durch Hersteller den Erfolg von XML Schema gefährden. Unklar ist in diesem Zusammenhang die Position von Microsoft. Die Gates-Company brachte die Schema-Entwicklung durch den Vorschlag von "XML-Data" Anfang 1998 in Gang. Mittlerweile firmiert diese Schemasprache unter der Bezeichnung "XML-Data Reduced" (XDR). Der Microsoft-Vorstoß wurde nicht zur W3C-Empfehlung weiterentwickelt, weil sich der Windows-Hersteller der Arbeitsgruppe XML Schema anschloss. Dort übte die Firma wohl erheblichen Druck auf die anderen Teilnehmer aus, Schemata kompatibel mit XML-Data zu gestalten (siehe dazu http://www.seyboldreports.com/News/2000/20000307.html). Microsoft nutzt XDR im Rahmen der Biztalk-Initiative, die neben dem Schema-Repository unter http://www.biztalk.org auch Software in Form des Biztalk-Servers umfasst. Der Parser in der Laufzeitbibliothek MSXML, der auch Bestandteil des "Internet Explorer" ist, kann seit der Version 2.0 Dokumente gegen XDR-Schemata validieren. Sie unterstützt bisherige Entwürfe von XML Schema aber noch nicht. Microsoft bekundete jedoch die Absicht, nach Verabschiedung der W3C-Empfehlung XDR fallen zu lassen.

Nach Vorstellung des W3C sollen mit Verabschiedung der Schemaempfehlung auch andere Vorschläge hinfällig werden, die an das Gremium eingereicht wurden. Dazu zählt die Document Content Description for XML (http://www.w3.org/TR/NOTE-dcd), die eine Teilmenge von XDR konform mit dem Resource Description Framework (RDF) formuliert. XML Schema soll zudem auch an die Stelle des Schema for Object-Oriented XML und (http://www.w3.org/TR/NOTE-SOX) und der Document Definition Markup Language (DDML, http://www.w3.org/TR/NOTE-ddml) treten. Letztere wurde von der deutschen GMD eingereicht und hieß vorher XSchema.

Ob die W3C-Variante einer Schemasprache einen anderen Rivalen namens "Relax" (http://www.xml.gr.jp/relax) verdrängen kann, ist allerdings weniger klar. Dieses Konkurrenzmodell wurde von einem japanischen Team um Murata Makoto entwickelt. Es ist im Gegensatz zum monolithischen XML Schema modular aufgebaut und vereinfacht dadurch die Migration von DTDs. Relax wurde unter dem Schirm des japanischen Gremiums Information Technology Research and Standardization Center (Instac) entwickelt, vor kurzem wurde die Kernspezifikation zur Standardisierung bei der ISO eingereicht.

Ungewiss ist schließlich, ob sich DTDs überhaupt so schnell ablösen lassen - immerhin existiert bei den Anwendern eine Vielzahl solcher Dokumenttyp-Definitionen. In dokumentorientierten Umgebungen ist der Bedarf nach den neuen Schema-Features ohnehin nicht so groß, für den Datenaustausch gibt es Bemühungen, DTDs entsprechend zu erweitern. Zu solchen Vorhaben zählt "Data Types for DTDs", das von der Firma Extensibility (http://www.extensibility.com/dt4dtd) unter Mitwirkung des SGML-Erfinders Charles Goldfarb vorangetrieben wird.

Definition eines Adresselements

DTD...

<!ELEMENT address (company?, name, street+, city, state, zip)>

... versus Schema

<elementType name="address">

<sequence>

<elementTypeRef name="company" minOccur="0" maxOccur="1"/>

<elementTypeRef name="name" minOccur="1" maxOccur="1"/>

<elementTypeRef name="street" minOccur="1" maxOccur="2"/>

<elementTypeRef name="city" minOccur="1" maxOccur="1"/>

<elementTypeRef name="state" minOccur="1" maxOccur="1"/>

<elementTypeRef name="zip" minOccur="1" maxOccur="1"/>

</sequence>

</elementType