Die Geschichte von XML

(Auszug aus "Perl & XML" von Erik T. Ray & Jason McIntosh)

Die Textverarbeitung war ursprünglich eng mit den Maschinen verbunden, auf denen die Ausgabe der Daten erfolgte. Präzise Formatierung war an ein gewisses Gerät gebunden – genauer, an eine bestimmte Klasse von Geräten, die Drucker.

Nehmen wir zum Beispiel troff . Dies ist eine ältere Textbeschreibungssprache, die in den verschiedenen Unix-Distributionen enthalten war und ist und dort früher sehr populär war. Die Sprache war revolutionär, weil sie Textausgabe in Spitzenqualität ohne eine Druckerei erlaubte.

troff verbindet Formatierungsanweisungen mit den eigentlichen Daten. Die Anweisungen sind Symbole, die ihrerseits aus lesbaren Zeichen bestehen und einer speziellen Syntax unterliegen, die dem troff-Interpreter die Abgrenzung der Symbole von den Daten ermöglichen. Zum Beispiel wird mit \fI die Kursivschrift eingeschaltet. Ohne den Backslash wären die Zeichen fI ganz normale Textdaten. Diese Mischung aus Anweisungen und Daten wird als Markup bezeichnet.

troff kann unglaublich detailliert sein. Mit der Anweisung .vs 18p fügt man an einer beliebigen Stelle des Dokuments ein exakt 18 Punkte breites Leerzeichen ein. Für die Ästhetik eines Textes ist diese präzise Positionierung natürlich hervorragend. Die Anweisung an den troff-Interpreter ist absolut unmißverständlich. Für alles andere ist eine solche Anweisung aber eher hinderlich. Die Sprache troff ist damit wirklich ausschließlich zum Drucken von Dokumenten brauchbar, für alles andere ist sie eher ungeeignet. Wenn man ein troff-Dokument verändern will, bekommt man das sehr schnell zu spüren.

Stellen wir uns einmal vor, wir hätten dieses Buch in troff geschrieben und jeden neu eingefügten Begriff mit Fettdruck hervorgehoben. Das Dokument würde Hunderte von fettgedruckten Begriffen enthalten. Plötzlich kämen neue Vorgaben für die Gestaltung: Neue Begriffe sollten jetzt in Kursivschrift stehen.

Der erste Gedanke wäre natürlich, mit einem Texteditor einfach die Markup-Zeichen für Fettdruck in diejenigen für Kursivschrift zu ändern. Aber leider ist da noch ein Problem: Gelegentlich wird Fettdruck auch für Hervorhebungen verwendet. Der Texteditor ist nicht in der Lage, das zu unterscheiden; eine automatische Konversion scheidet also aus. Uns bleibt nichts anderes übrig, als durch den Text zu gehen und bei jeder Stelle mit Fettdruck aus dem Kontext heraus zu entscheiden, ob hier ein neuer Begriff definiert wird oder nicht. Das dürfte Stunden, wenn nicht gar Tage in Anspruch nehmen.

Man kann eine Formatierungssprache wie troff so ausgetüftelt machen, wie man will, es bleibt immer dasselbe Problem: Im Grunde genommen ist sie doch präsentationsorientiert. Eine präsentationsorientierte Markup-Sprache beschreibt in erster Linie das Aussehen des Inhalts. troff beschreibt alle Details des Zeichensatzes und der Positionierung, ist aber völlig losgelöst vom logischen Inhalt. Ein troff-Dokument ist in verschiedenen Dingen unhandlich. Zum Beispiel ist es schwer, im Dokument nach dem letzten Absatz im dritten Kapitel eines Buches zu suchen. Immer dann, wenn das Dokument zu einem anderen Zweck als zum Drucken geöffnet wird, ist der präsentationsorientierte Markup im Weg.

Wir können troff als ein Zielformat auffassen. Sein Zweck besteht nicht in der Weiterverarbeitung oder Veränderung, sondern einzig und allein in einem bestimmten, abschließenden Vorgang. Was könnte es für andere Formate geben? Gibt es zum Beispiel ein »Ausgangsformat«, also etwas, das sich nicht der Formatierung widmet, aber trotzdem Daten in einem nützlichen Format verpackt? Diese Schlüsselfrage kam in den späten Sechzigern auf, als das Konzept einer generischen Codierung entwickelt wurde: Markup wurde verwendet, um den textuellen Inhalt in einer Art und Weise zu beschreiben, die an  der Ausgabe nicht interessiert war. Die verwendeten Tags hatten eher beschreibenden als visuellen Charakter.

Von der Graphic Communications Association (GCA) wurde ein Projekt namens GenCode zur Erforschung dieses neuen Themas gestartet. Ziele des Projekts waren die Codierung von Dokumenten in generischen Tags und der Aufbau eines Dokuments aus kleinen Bausteinen – man könnte es als Vorgänger von Hypertext sehen. Die Generalized Markup Language (GML), entwickelt von Charles Goldfarb, Edward Mosher und Raymond Lorie im Auftrag der IBM, baute auf diesem Konzept auf (Anmerkung: Falls es ihnen nicht aufgefallen ist: Die Initialen der Entwickler sind »GML«.). Als Ergebnis dieser Arbeit war IBM in der Lage, ein Dokument mit unterschiedlichen Programmen zu bearbeiten, zu drucken und auf einem Terminal darzustellen. Bedenkt man, daß alleine dieses Unternehmen Jahr für Jahr Millionen von Seiten an externer und interner Dokumentation produziert, dann versteht man, wie wichtig dieser Schritt war.

Goldfarb fuhr damit fort, ein Standardisierungsteam am American National Standards Institute (ANSI) zu leiten, das GML der Welt zugänglich machen sollte. Das Komitee entwickelte aus GML und GenCode die Standard Generalized Markup Language (SGML). Diese Sprache wurde praktisch sofort vom US-Verteidigungsministerium und verschiedenen Finanzbehörden übernommen, und SGML war damit von Beginn an ein enormer Erfolg. Zu einem internationalen Standard wurde die Sprache von der ISO im Jahre 1986 erhoben. Seit damals wurden unzählige Programme und Werkzeuge zur Publizierung und Verarbeitung von SGML entwickelt.

Generische Codierung bedeutete den Durchbruch für digitale Inhalte. Endlich konnte man den logischen Inhalt beschreiben, ohne sich auf die Darstellung zu konzentrieren. Ein Dokument wie das folgende wirkt eher wie eine Datenbank als eine Textverarbeitungsdatei:

<personnel-record>
  <name>
    <first>Rita</first>
    <last>Bucher</last>
  </name>
  <birthday>
    <year>1969</year>
    <month>4</month>
    <day>23</day>
  </birthday>
</personnel-record>

Beachten Sie, daß präsentationsorientierte Angaben völlig fehlen. Wie Sie den Namen ausgeben wollen, ist Ihre eigene Sache. Sie können nach Belieben »Bucher, Rita« oder »Rita Bucher« schreiben oder beide Namen in je einer Zeile anzeigen. Das Datum kann im europäischen Stil (23.4.1969), im amerikanischen (4/23/1969) oder im englischen (23/4/1969) angezeigt werden, der Monat kann als Name geschrieben werden usw. Das Dokument gibt keine bestimmte Anwendung vor. Dadurch ist es für viele verschiedene Zwecke verwendbar.

Trotz seiner revolutionären Fähigkeiten schaffte SGML bei kleineren Unternehmen nie wirklich den Durchbruch, zumindest nicht ansatzweise in demselben Maß wie bei großen. SGML-Software ist aufwendig und teuer. Man braucht ein ganzes Team von Entwicklern, um eine SGML-Produktionsumgebung aufzusetzen – wenn man vorhandene Software hat. SGML ist bürokratisch, verwirrend und ressourcenfressend. In seiner originalen Form war SGML nicht in der Lage, die Welt im Sturm zu erobern.

»Oh, wirklich?« sagen Sie. »Aber was ist mit HTML? Ist HTML nicht eine Anwendung von SGML?« HTML – der Promi des Internet, der Erfolgshit des Hypertexts und das Arbeitspferd des World Wide Web – ist in der Tat eine Anwendung von SGML. Unter einer Anwendung verstehen wir in diesem Fall eine Markup-Sprache, die mit Hilfe der Regeln von SGML entwickelt wurde. SGML ist keine Markup-Sprache, sondern ein Werkzeug zur Entwicklung eigener Markup-Sprachen. Von HTML abgesehen, gibt es auch andere Sprachen zur Codierung technischer Dokumentation, z. B. IRS-Formulare oder texinfo.

HTML ist im Gegensatz zu SGML enorm erfolgreich, hat aber seine deutlichen Grenzen. Es ist eine sehr kleine Sprache, und sie ist weniger der Beschreibung eines Dokuments gewidmet. Die Sprache ist näher an troff als an DocBook und anderen SGML-Anwendungen.

Das war nicht immer so. HTML hat als eine Art minimales DocBook angefangen, wurde dann aber speziell durch die »Browserkriege« zwischen Netscape und Microsoft in diese Richtung gedrängt. – Anm. d. Ü.

Sie besitzt Tags wie <i> und <b> , die den Stil des Zeichensatzes wechseln, ohne den Grund anzugeben. Man kann HTML nicht unbedingt als durchschlagenden Erfolg für SGML verbuchen, weil es so limitiert und präsentationsorientiert ist. Zumindest sind die beiden Sprachen im Geiste verschieden: Statt die Kraft der generischen Codierung zum Endbenutzer zu bringen, vermag HTML nicht mehr als Dokumentinhalte in einem besonderen Medium darzustellen.

Aus diesem Grund entschieden sich die Standardisierungskomitees für einen neuen Versuch, der ein Kompromiß zwischen der beschreibenden Kraft von SGML und der Einfachheit von HTML sein sollte. Das Ergebnis war die Extensible Markup Language (XML). Das »X« steht für »extensible«, also erweiterbar, und weist damit auf den ersten offensichtlichen Unterschied zu HTML hin. (Viele Leute finden, daß ein »X« in einem Akronym viel cooler klingt als ein »E«.) Der zweite und wichtigere Unterschied ist, daß man nicht auf die minimale Menge von HTML-Tags beschränkt ist. Man kann den Namensraum der Tags nach Belieben aufblähen und so beschreibend wie möglich machen – genauso beschreibend wie bei SGML. Voilà! Die Brücke ist gebaut.

Ohne Zweifel ist XML ein Riesenerfolg. Es hat seinen eigenen Hype überlebt und wächst durch die Präsentation darauf basierender Standards ständig weiter: XML-RPC, XHTML, SVG und DocBook XML sind nur einige der erfolgreichsten Produkte. Es gibt eine Reihe unterstützender Technologien wie z. B. XSL:FO für die Formatierung, XSLT für die Transformation, XPath für die Suche nach Dokumenten oder Teildokumenten und XLink für die Erstellung von Hyperlinks. Die meisten dieser Standardisierungen geschehen unter der Aufsicht des World Wide Web Consortium (W3C), einer Organisation, die unter anderem Microsoft, Sun, IBM und viele akademische und öffentliche Institutionen zu ihren Mitgliedern zählt.

Die Aufgabe des W3C ist die Erforschung und Entwicklung neuer Technologien für das Internet. Das ist ein sehr weit gefaßter Begriff, aber wenn Sie sich die Zeit nehmen, einige Minuten die Website http://www.w3.org/ zu durchstöbern, dann werden Sie feststellen, daß es diesem Auftrag gerecht wird und auf praktisch allen Feldern tätig ist. Das W3C entwickelt Standards nicht, um anschließend ihre Einhaltung zu überwachen oder gar Lizenzen zu berechnen. Statt dessen werden sie als Empfehlung an die Entwickler verstanden, die sich daran halten sollen, es aber keineswegs müssen.

Da das W3C ein enormes Vertrauen genießt, haben seine Empfehlungen aber oft geradezu den Status eines Gesetzes. Entwickler richten sich nach den Empfehlungen, sobald sie freigegeben werden, oft sogar schon während der Standard noch im Entstehen ist. Wer die Kompatibilität mit anderen als Ziel seiner Software sieht, wird die Standards des W3C als bindend empfinden (genau das ist der Punkt bei Standards).

Das System ist aber offen genug für Dissens und Diskussion. Man hat das im Falle von XML Schema gesehen, einem W3C-Standard, der sehr umstritten war und einen gewissen Wettstreit ausgelöst hat. Wir kommen auf diese Geschichte in XML-Grundlagen: Lesen und Schreiben noch zurück. Das W3C ist stark genug, um ernstgenommen zu werden, aber auch locker genug, den Leuten die nötige Flexibilität zu lassen. Die Empfehlungen der Organisation sind stets öffentlich verfügbar.

Jeder Entwickler sollte heute eine gewisse Erfahrung mit XML haben, da es die universale Sprache zur Verpackung von Daten ist. Die meisten Programme werden entwickelt, um Daten zu verarbeiten, die in irgendeiner Form verpackt sind. Im weiteren Verlauf dieses Abschnitts geben wir eine kurze Einführung in XML für Entwickler.

  

  

<< zurück vor >>

 

 

 

Tipp der data2type-Redaktion:
Zum Thema Perl & XML bieten wir auch folgende Schulungen zur Vertiefung und professionellen Fortbildung an:

Copyright © 2003 O'Reilly Verlag GmbH & Co. KG
Für Ihren privaten Gebrauch dürfen Sie die Online-Version ausdrucken.
Ansonsten unterliegt dieses Kapitel aus dem Buch "Perl & XML" denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

O’Reilly Verlag GmbH & Co. KG, Balthasarstraße 81, 50670 Köln, kommentar(at)oreilly.de