Derzeit sieht es gar nicht schlecht für die weitere Ausbreitung von XML aus. Konzerne wie Microsoft und die damit verfeindete Unix-Welt sind sich weitgehend einig, dass XML die Zukunft gehört, was die einheitliche Speicherung von Daten betrifft. Doch es wird schnell deutlich, warum es schwierig ist, XML einer breiteren Anwenderschicht zu vermitteln. Denn XML ist eigentlich etwas für Leute, die Dateiformate definieren, und das ist naturgemäß eine Minderheit. "Normale" Anwender, auch professionelle, kommen mit XML wohl eher am Rande in Berührung. Sie sind eher diejenigen, die diese Auszeichnungssprachen anwenden müssen, sei es auf Quelltext-Ebene oder mit Hilfe von Software-Oberflächen, die visuelles Arbeiten erlauben und das XML-Format einfach zur Speicherung der Daten benutzen.
Die prominenteste der Sprachen, die mit Hilfe von XML definiert werden, ist derzeit zweifellos die neue Fassung von HTML, XHTML genannt. Aber auch andere bekannte Sprachen, wie etwa WML (Beschreibungssprache für das WAP-Protokoll, das Internet-Inhalte aufs Handy-Display bringt), kommen ins Gespräch. Welcher Erfolg all diesen Sprachen beschieden ist, entscheidet der Markt. Daneben bietet XML jedoch auch die Möglichkeit an, völlig neue Sprachen zu definieren, die für eigene Datenstrukturen optimal angepasst sind, und die aber trotzdem nicht proprietär sind, sondern einem standardisierten Regelwerk folgen.
XML ist für viele Anwender deshalb etwas schwer "greifbar", weil es eigentlich nicht viel tut. Seine Leistung besteht darin, dass man mit den Konzepten und Regeln, die es bereitstellt, eigene Auszeichnungssprachen definieren kann, die ähnlich funktionieren wie HTML. All diese Sprachen bestehen immer wieder aus Elementen, markiert durch Tags, deren Verschachtelungsregeln, und aus Attributen mit erlaubten Wertzuweisungen. Daneben gibt es Regeln, wie man solche Sprachen - in XML auch Namensräume genannt - in andere Sprachen importieren und somit eine Sprache innerhalb einer anderen Sprache benutzen kann.
<rechteck oben="100" links="185" breit="427" hoch="110"> <hintergrund typ="verlauf" richtung="waagerecht" startfarbe="#0000FF" endfarbe="#FFFFFF"> <inhalt typ="text" format="stil_6">; < Ein kleiner Text> </inhalt> </hintergrund> </rechteck> </pre> <projekt sprache="perl" name="Performance-Test IC-Baustein TL410" typ="shell" stand="02-10-2001"> <modul name="main" stand="02-10-2001" ablage="/usr/scripts/tl410/tl410.pl"> <funktion name="datenversorgung" stand="14-09-2001"> <beschreibung> </beschreibung> </funktion> </modul> </projekt>
Die beiden Beispiele enthalten ganz unterschiedliche Elemente, Attribute, Wertzuweisungen und typische Verschachtelungen. Gemeinsam ist ihnen jedoch, dass sie offensichtlich aus bestimmten erlaubten Elementen, Attributen, Wertzuweisungen und Regeln zur Verschachtelung bestehen. In den beiden Beispielen finden Sie diese Regeln nirgendwo beschrieben. Insofern sind es einfach Phantasiebeispiele. Es gibt jedoch ein standardisiertes Verfahren, um solche Regeln zu definieren und in den Auszeichnungssprachen anzugeben, auf welche Regeln man sich bezieht und wo diese Regeln definiert sind. Dieses standardisierte Verfahren ist XML.
Als Vorübung zu XML empfiehlt es sich durchaus, wenn Sie einfach mal versuchen, irgendeine Datenstruktur, mit der Sie viel zu tun haben, mit Hilfe solcher phantasierter Elemente, Attribute, Wertzuweisungen und Tag-Verschachtelungen zu beschreiben. Beschreiben Sie beispielsweise mal die Organisationsstruktur Ihres Unternehmens auf diese Weise, oder Ihren typischen Tagesablauf, oder den Grundriss Ihrer Wohnung. Dabei werden Sie schnell feststellen, dass es oft mehrere Wege gibt, um ein und dieselbe Struktur zu definieren. Im zweiten der obigen Beispiele hätte man beispielsweise das Element, das durch
Für welchen Zweck Sie ein eigenes Element spendieren, oder was Sie in ein Attribut packen, gehört zu den Aufgaben des Sprachen-Designs. Wenn Sie sich diese Problematik einmal an eigenen, konkreten Beispielen klarmachen, haben Sie schon sehr viel von XML begriffen, ohne die einzelnen Details von XML zu kennen.
Das Verfahren mit den DTDs und der Validierung mag Ihnen anfangs etwas umständlich und aufwendig erscheinen. Doch nur durch dieses Verfahren ist sichergestellt, dass XML-Sprachen nicht nur Phantasiegebilde sind, sondern Sprachen, die sich an bestimmte, genau definierte Regeln halten. Nur so ist es möglich, dass sich verschiedene Autoren und verschiedene Software-Produkte an die Konventionen einer Sprache halten und die Sprache nicht durch spontane, undefinierte Erweiterungen verwässert und für interpretierende Software unbrauchbar wird. Eine XML-Sprache zu erweitern ist durchaus möglich, aber wenn, dann auf dem dafür vorgesehenen Weg, nämlich durch Erweiterung der entsprechenden DTD.
Das obige Beispiel ist natürlich nur sehr einfach. In der Praxis können Sie beliebig komplexe Datenstrukturen und deren Beziehungen mit Hilfe der DTD-Syntax definieren. Im Abschnitt Dokumenttyp-Definitionen (DTDs) finden Sie detailliertere Erklärungen dazu, wie man eine XML-gerechte DTD erstellt.
Während die meisten Software-Hersteller noch im seligen Schlaf liegen, beweist der vielgehasste Microsoft-Konzern mal wieder seine Chamäleon-Qualitäten. Mit gewaltigem finanziellen Aufwand arbeitet das angeschlagene Unternehmen daran, die verbreitete Office-Familie, bestehend aus Word, Excel, Powerpoint und Access, komplett auf XML-basierte Dateiformate umzustellen. Aber auch andernorts wachen die Hersteller allmählich auf. Vor allem das vom W3-Konsortium entworfene, XML-basierte SVG-Dateiformat für Vektorgrafik erweist sich dabei als vielversprechend.
XML könnte dafür sorgen, dass es in Zukunft egal ist, womit Sie Ihre Briefe schreiben, Ihre Häuser konstruieren oder Ihre Plakatwerbung erstellen. Wenn die benutzte Software sich konsequent an den XML-Standard hält und nachweisbare Dokumenttypen (DTDs) benutzt, dann steht einem verlustfreien Portieren von Daten zwischen konkurrierenden Anwendungen mit gleichen Fähigkeiten eigentlich nicht mehr viel im Wege.
Ein wichtiger Pluspunkt von XML ist, dass Daten und Layout völlig voneinander getrennt sind. Nicht einmal die Ausgabeform der Daten ist festgelegt. Aus dem gleichen XML-Datenbestand lässt sich eine Web-Seite generieren, eine Druckvorlage oder eine akustische Ausgabe mit künstlichen Stimmen. Es gibt nur noch eine Datenquelle, und das Publizieren erfolgt mit Hilfe von Konvertern, die XML-Daten in andere Daten (z.B. in HTML oder in PostScript) übersetzen. Die klassischen, zuletzt immer monströser gewordenen Programme mit ihren hauseigenen Formaten werden deshalb zunehmend kleineren Software-Modulen weichen, deren Stärke das Zusammenspiel ist. Das Konzept dieser Modularisierung ist zwar schon älter, aber es fehlten zunächst die Schnittstellen. XML jedoch leistet eine solche Schnittstelle auf der Ebene der Datenformate.
Ein Parser muss nicht auf der Client-Seite (im Browser) integriert sein. Er kann genausogut in die Umgebung eines Web-Servers eingebunden sein und Daten, die auf dem Server abgelegt sind und vom Browser über HTTP angefordert werden, schon umwandeln, bevor diese überhaupt übers Internet übertragen werden. Genau dies tut beispielsweise ein server-seitiger XSLT-Parser, der XML-Daten in HTML-Daten übersetzen kann. Ein Browser, der die XML-Daten über HTTP angefordert hat, erhält dann vom Server leicht verdaulichen HTML-Code.
Generell kann man unterscheiden zwischen Parsern, die den Quelltext validieren, und solchen, die das nicht tun. Validierende Parser erwarten zu allen XML-Daten eine DTD und prüfen den gesamten Inhalt der XML-Daten gegen die zugehörige DTD. Ergibt die Prüfung Fehler, geben solche Parser beispielsweise Fehlermeldungen aus und brechen die Verarbeitung ab.
Der Internet Explorer interpretiert beliebige, XML-basierte Auszeichnungssprachen seit der Produktversion 5.0, der Netscape-Browser ab seiner völlig neu programmierten Version 6.0. "Interpretieren" meint dabei, dass diese Browser XML-Daten als solche erkennen und parsen können. Schick darstellen können sie die Daten deshalb noch nicht - dazu sind Formatierungen mit CSS oder XSL oder Übersetzungen mit XSLT in HTML erforderlich.
Da Web-Designer meistens auch auf ältere Produktversionen oder andere Browser Rücksicht nehmen müssen, empfiehlt es sich vorläufig nicht, Web-Design unmittelbar mit XML-basierten Sprachen zu betreiben. Nur wenn XML in Verbindung mit XSLT und dessen serverseitigen Interpretation einsetzbar ist, ist die Verwendung im Web heute unbedenklich.
XML gewinnt auf jeden Fall mehr und mehr Bedeutung bei der Datenhaltung umfangreicher, reich strukturierter Datenbestände. Bei großen Web-Sites mit viel und einheitlich strukturiertem Inhalt werden die Daten immer häufiger in XML-basierten, eigenen Dateiformaten gespeichert. Bis es jedoch problemlos möglich sein wird, XML-Daten direkt an aufrufende Browser zu senden, wird noch einige Zeit vergehen.
DTDs und Validierungt
Die Regeln für erlaubte Elemente, Attribute und Verschachtelungsmöglichkeiten einer XML-gerechten Auszeichnungssprache werden unabhängig von den eigentlichen Daten definiert. Die Daten mit den Definitionen stellen eine so genannte Dokumenttyp-Definition (engl. document type definition, Abkürzung DTD) dar. XML-fähige Software sollte idealerweise in der Lage sein, solche DTDs auszulesen und Daten, die auf diese DTD Bezug nehmen, nach den Regeln der DTD beurteilen zu können (siehe auch Aufgaben von XML-Parsern). Dabei kann die interpretierende Software feststellen, ob innerhalb der XML-Daten, die sich auf eine bestimmte DTD beziehen, ungültige Notationen vorkommen. Ungültige Notationen sind z.B. Element- oder Attributnamen, die in der DTD nicht definiert werden, oder Elemente an Stellen, an denen sie aufgrund der DTD-Regeln nicht erlaubt sind. Das Verfahren, um zu überprüfen, ob eine XML-Datei nach den Regeln ihrer zugehör!
igen DTD fehlerfrei ist, nennt man Validierung (von engl. valid = gültig). Beispielauszug aus einer DTD
Auf die genaue Syntax beim Definieren wird an dieser einführenden Stelle nicht weiter eingegangen. Das Beispiel möchte lediglich einen ersten Eindruck vermitteln, wie DTD-Definitionen aussehen, und welche Konsequenzen sie haben. In dem Beispiel werden verschiedene Elementtypen definiert. Das sind die "logischen Vorlagen" für Elemente, die in einer XML-Sprache, die sich auf diese DTD bezieht, vorkommen können. Eine Definition wie z.B. bedeutet, dass es in dieser XML-Sprache ein Element titel gibt, das durch die Tags
<!ELEMENT nachricht (titel,text,datum,redakteur)>
<!-- Eine Nachricht besteht aus Titel, Text, Datum und Redakteur -->
<!ELEMENT titel (#PCDATA)>
<!-- Der Titel enthaelt den Titeltext, sonst nichts -->
<!ELEMENT text (#PCDATA)>
<!-- Der Text enthält den Nachrichtentext, sonst nichts -->
<!ELEMENT datum (#PCDATA)>
<!-- Das Datum enthaelt die Datumsangabe, sonst nichts -->
<!ELEMENT redakteur (#PCDATA)>
<!-- "redakteur" enthaelt die Angabe zum Redakteur, sonst nichts -->
Erläuterung
Beispieldaten aufgrund der DTD
<nachricht>
<titel>XML wird jetzt auch in SELFHTML beschrieben!
Nach langer Pause ist eine neue SELFHTML-Version erschienen. Eine der wichtigsten
Neuerungen ist der XML-Teil, in dem die neue Definitionssprache für Auszeichnungssprachen
behandelt wird. Der Anwender lernt, wie er Regeln definiert, und Beispiele
ergänzen die Beschreibungen.
</text>
<datum>20.10.2001Ferdinand Schreiberling
Erläuterung
Dem Beispiel können Sie entnehmen, dass die Regeln, die zuvor in der Beispiel-DTD definiert wurden, eingehalten wurden. Es gibt das übergreifende Element nachricht, ausgezeichnet durch die Tags XML und der Software-Markt
Für den klassischen Software-Markt stellt XML eine gewaltige Provokation dar. Denn es ist ein Generalangriff auf alle proprietären Dateiformate, die an bestimmte, oft teuere Programme gebunden sind. Durch XML entsteht aus Anwendersicht etwas Neues: im Vordergrund steht nicht mehr das Software-Produkt als Einheit von Benutzeroberfläche und Dateiformat, sondern nur noch die Benutzeroberfläche, und gleichzeitig die Erwartung, dass die Daten, die zu erzeugen oder zu verarbeiten sind, in einem modernen, XML-basierten Dateiformat abgespeichert werden. Der Wettbewerb zwischen konkurrierenden Software-Produkten verlagert sich deshalb auf das "Interface-Design". Denn wenn vergleichbare Produkte die gleichen, standardisierten Dateiformate verwenden und den Anwender nicht mehr durch das Dateiformat an sich binden können, müssen sie den Anwender durch überlegene Benutzerführung und eine praxisnahe Arbeitsebene überzeugen. Durch die universell!
e Anwendbarkeit von XML gilt dies für fast alle Software-Typen, egal ob Textverarbeitung, Grafik, Tabellenkalkulation, Datenbank, CAD, Musik oder sogar Computer-Spiele.Die Aufgaben von XML-Parsern
Was man in prozeduralen Sprachen, also in Programmiersprachen, als Interpreter bezeichnet, nennt man in beschreibenden Sprachen wie XML einen Parser (auch: Prozessor). Bei XML ist ein Parser diejenige Software, die XML-Strukturen ausliest, analysiert und nachgeschalteter Software zur Verfügung stellt. Ein XML-fähiger Browser beispielsweise besitzt ein eigenes Software-Modul, das den Parser darstellt. Im Parser wird die Baumstruktur der XML-Daten analysiert. Ein erfolgreiches Analysieren dieser Struktur ist die Voraussetzung für eine korrekte Darstellung/Wiedergabe der Daten. XML und die Browser
Das entscheidende Problem beim Erfolg von XML ist die Fähigkeit von Software, XML-basierte Daten vollständig und adäquat zu repräsentieren. Egal, ob es sich um Textdaten, Grafikdaten, numerische Daten oder Multimediadaten handelt. Web-Browser sind heute der Software-Typ, der am stärksten mit unterschiedlichen Dateiformaten konfrontiert wird und für eine ansprechende Umsetzung dieser Daten am Bildschirm oder an anderen Ausgabegeräten zu sorgen hat. Außerdem sind Web-Browser von vorneherein internet-fähig, was für XML ebenfalls wichtig sein kann. Denn XML-fähige Software muss gegebenenfalls auf öffentlich im Internet hinterlegte Dokumenttyp-Definitionen zugreifen können, um eine Datei, die nach den Regeln eines bestimmten Dokumenttyps kodiert ist, interpretieren zu können. Insofern haben die Browser eine gewisse Vorreiterrolle, was die Umsetzung der XML-Philosophie in der Praxis betrifft.