Websperanto

Von: Dr. Klaus Schlüter

XML ist garantiert nicht die

letzte Markup-Sprache!" – mit dieser eher beiläufigen Bemerkung verblüffte einer der Schöpfer der "Extended Markup Language" (XML) seine Zuhörer auf einer Konferenz der Software AG im österreichischen Bad Fuschl. Tim Bray, der sich selbst als verhinderten Poeten, aber erfahrenen Datenbankingenieur bezeichnet, nahm seine Zuhörer mit auf eine Bildungsreise durch die Theorie der Markup-Sprachen. Er beantwortete die Frage, warum ausgerechnet XML so wichtig fürs Web sei und führte die Teilnehmer schonend in den Gebrauch des neuen Metadialekts ein. Wir haben ihn dabei begleitet, Tagebuch geführt und eigene Eindrücke mitverarbeitet.

Theorie der Markup-Sprachen

Innerhalb von Texten dienen "Markups" dazu, Buchstaben, Wörter oder Passagen "herauszustellen". Wir haben uns so sehr an ihr Vorhandensein gewöhnt, daß wir sie in der Regel überhaupt nicht mehr wahrnehmen. Erst ihr Fehlen erinnert uns daran, wie wichtig beispielsweise Leerräume oder Satzzeichen als Markups sind:

esgibtdreiartenvonmarkupsprachendierepräsentativendieprozeduralenunddiedeskriptiven

Auch die Groß- und Kleinschreibung hat, wie das Beispiel zeigt, eine Markup-Funktion, was bei Farben und Fonts nicht eigens betont werden muß. Mit gängigen Markups liest sich der obige Satz viel leichter:

Es gibt drei Arten von Markup-Sprachen:

- die repräsentativen,

- die prozeduralen und

- die deskriptiven.

In einer repräsentativen Markup-Sprache kann ein Autor genau ein Text-Layout beschreiben, und zwar in allen Details. Typische Vertreter dieser Gattung sind Programme wie "troff" oder "TEX". Mit einer prozeduralen Sprache wird ein Ausgabegerät angewiesen, an bestimmten Positionen Punkte zu setzen. In der Regel erledigt das nicht der Autor selbst, sondern ein eigens dafür entwickelter Konverter. Das folgende, stellenweise gekürzte ("...") rtf-Beispiel deutet an, warum:

{\rtf1\ansi \deff4\deflang1033

{\fonttbl{\f1\froman\fcharset2\fprq2 Symbol;}{\f4\froman\fcharset0\fprq2

Times New Roman;}}{\colortbl;\red0

\green0\blue0;\red0\green0\blue255;

...

{\stylesheet{\f4\fs20\lang1031 \snext0 Normal;}{\*\cs10 \additive Default Paragraph Font;}{\s15\li3240\keep \f4\lang1031 \sbasedon0\snext15

envelope address;}}{\info{\author Klaus Schl\’fcter}{\creatim\yr1998\mo12\dy31

\hr16\min11}{\version1}{\edmins0}{\nofpages0}{\nofwords0}{\nofchars0}{\vern49205}}\paperw11906\paperh16838\margl1417

\margr1417\margt1417\margb1134 \deftab708\widowctrl

...

\pard\plain \f4\fs20\lang1031 Es gibt drei Arten von Markup-Sprachen:

\par \pard {{\field{\*\fldinst SYMBOL 183 \\f „Symbol“ \\s 10}{\fldrslt\f1\fs20}}} die repr\’e4sentativen,

\par {{\field{\*\fldinst SYMBOL 183 \\f „Symbol“ \\s 10}{\fldrslt\f1\fs20}}}

die prozeduralen und \par {{\field{\*\fldinst SYMBOL

183 \\f „Symbol“ \\s 10}{\fldrslt\f1\fs20}}} die

deskriptiven.

\par \pard

\par}

Wer genau hinsieht, erkennt das bereits zweimal erwähnte Beispiel wieder. Kein Mensch könnte jedoch auf diese Art und Weise längere Briefe, geschweige denn Bücher verfassen: Der Aufwand wäre schlicht zu hoch und das Ausmerzen von Fehlern vermutlich eine Lebensaufgabe. Dennoch arbeiten Programme wie Word oder Wordperfect mit prozeduralen Markup-Sprachen, allerdings im Verborgenen und unbemerkt vom Anwender. "What you see is what you get" (Wysiwyg) lautet deren Maxime – eine Lüge, wenngleich auch keine bewußte. Denn gäbe man tatsächlich die 72 dpi des Monitors auf einem Drucker mit 1440 dpi aus, so stäche das grob gerasterte Schriftbild unangenehm ins Auge.

Deskriptive Markup-Sprachen legen sich im Gegensatz zu den repräsentativen und den prozeduralen nicht auf ein bestimmtes Layout fest, sondern lassen dem Anwender die Freiheit, die übermittelten Informationen in eine seinen Zwecken angepaßte Repräsentation

einzubinden. In diesem Sinne ist beispielsweise die "Hyper Text Markup Language" (HTML) bereits eine deskriptive Markup-Sprache: Der Anwender kann beispielsweise die Fonts von Titeln, Zwischenüberschriften und Texten an die eigenen Bedürfnisse anpassen.

Das obige Beispiel könnte in einer deskriptiven Markup-Sprache etwa wie folgt beschrieben werden:

<Fließtext>Es gibt drei Arten von</p> <p> Markup-Sprachen:</p> <p> <Aufzählung></p> <p> <Punkt>die repräsentativen, <\Punkt></p> <p> <Punkt>die prozeduralen und <\Punkt></p> <p> <Punkt>die deskriptiven. <\Punkt></p> <p> <\Aufzählung></p> <p><\Fließtext>

Man beachte, daß dieses Beispiel weder in HTML noch in XML abgefaßt ist. Es verdeutlicht vielmehr das dahinterstehende Prinzip: Die Details des Layouts, also beispielsweise der Font des Fließtexts oder die Form des Aufzählungspunktes, können beim Sender und beim Empfänger der Botschaft unterschiedlich implementiert sein.

Doch warum eine neue Sprache, wenn die vorhandenen deskriptiven Sprachen, insbesondere die "Standard Generalized Markup Language" (SGML), die Bedürfnisse der Anwender bereits abdecken? De facto ist SGML zu umfangreich und zu kompliziert; allein die Dokumentation umfaßt circa 500 Seiten. In der Praxis wird SGML deshalb nur für große technische Dokumentationen verwendet und – was viele nicht wissen – zur Definition von HTML.

HTML legt mit einer Reihe von Tags fest, wie ein Dokument im Browser erscheinen soll, welche Links zu anderen Web-Seiten bestehen und ob eventuell Applets eingebunden werden sollen. Nicht zuletzt wegen des geringen Vokabulars ist HTML "die" Sprache des Webs. Allerdings hat sie angesichts der niedrigen Geschwindigkeit des Internets auch einen gewichtigen Nachteil: Sie verursacht eine besonders hohe Netzlast.

Von HTML zu XML

HTML bürdet dem Server die gesamte Arbeit auf, dem Client so gut wie keine. Denn während der Server die Informationen in vorhandenen Datenbeständen suchen, zusammenstellen und weiterleiten muß, bereitet sie der Client nur noch bildschirmgerecht auf. Warum also nicht die Intelligenz der Clients nutzen und die Serverlast verringern? Noch dazu, wo die Leistungsfähigkeit moderner PCs an die von Rechenzentren heranreicht, wie sie vor zwei Jahrzehnten ganze Stäbe beschäftigten.

Genau diesen Weg geht XML. Statt komplette Seitenbeschreibungsanweisungen übers Netz zu transportieren, läßt sie den Client weniger detaillierte Beschreibungen interpretieren und in eigene Repräsentationen umwandeln. Dieselbe Information kann daher in XML sehr viel knapper abgefaßt werden als in HTML. XML-Autoren beherzigen also gleichsam eine Art Telegrammstil, die beim Empfänger Mitdenken voraussetzt. Statt "Ich komme am Freitag, den 13. Februar, bei Euch zu Hause in Düsseldorf an" schreiben sie sinngemäß: "Ankomme 13. Februar."

Doch damit nicht genug. HTML kann keine Datenstrukturen spezifizieren, sondern nur Schriftstücke formatieren. Inhaltliche Aspekte bleiben außen vor. Je mehr jedoch die Ansprüche der Anwender steigen, desto dringlicher wird der Wunsch, Daten gerade nach solchen Gesichtspunkten zu strukturieren. Beispiel: Ein Verlag möchte die Produktion medienneutral durchführen, also Schriftstücke auf verschiedene Medien übertragen; die Beiträge sollen in Magazinen und Büchern, auf CDs und im Internet erscheinen. Hier bietet HTML zwar die Möglichkeit, den Autor kursiv und den Titel fett zu setzen, stellt aber keine Tags zur Verfügung, die den Autor als Autor und den Titel als Titel auszeichnen: Ein enormer Nachteil, gerade bei der medienneutralen Produktion.

Das Erfassen von Schlagworten, von Erscheinungsdatum und Versionsnummer, von Autorenadressen und -honoraren, von Kurzinhalten und -zusammenfassungen – all das sind Versuche, die jeweiligen Daten nicht nur als String zu behandeln, sondern auch inhaltlich einzuordnen. Weil aber jedermann mehr oder weniger individuelle Vorlieben hat, Dinge zu klassifizieren, ist beim Datenaustausch mit Schwierigkeiten zu rechnen, jedenfalls dann, wenn man sich nicht an gegenseitige Konventionen hält.

Versuche, die damit einhergehenden Probleme durch Erweiterungen von HTML zu beseitigen, würden die Markup-Sprache überfrachten und mitunter sogar das Ende des Webs heraufbeschwören. Außerdem ist es schlicht unmöglich, für jeden Bedarf eine formale Spezifikation festzulegen: HTML wäre damit – weil nicht modular – unbeherrschbar. XML umgeht diese Klippe durch sogenannte "Document Type Definitions" (DTDs), in denen jeder Autor eigene Tags definieren und sie der Allgemeinheit zur Verfügung stellen kann. Die XML-Spezifikation selbst umfaßt lediglich 40 Seiten, also nur einen Bruchteil der SGML-Spezifikation.

HTML kann auch als XML-Anwendung laufen, beides sind SGML-Applikationen. Damit erschließt sich den XML-Parsern bereits heute der siebte, virtuelle Kontinent, das Internet. Und aufgrund der Abwärtskompatibilität von XML kann der Übergang von HTML auf XML sukzessive erfolgen, was die Akzeptanz der neuen Universalsprache zweifellos erhöhen wird. Darüber hinaus definierten die Schöpfer von XML Designkriterien, wonach XML-Dokumente

- einem klaren, formalen Aufbau folgen sollten und außerdem

- menschenlesbar und prägnant,

- einfach zu verfassen und nicht

- notwendigerweise knapp sein sollten.

XML-fähige Programme sollten einfach zu entwickeln sein und nur eine minimale Anzahl, idealerweise keine, optionaler XML-Funktionen implementieren.

XML – quick and dirty

Nach all dem theoretischen Vorgeplänkel hier nun ein erstes konkretes Beispiel. Es soll den Einstieg erleichtern und ist an ein Vorbild aus [1] (siehe auch die Buchbesprechung auf Seite 117) angelehnt: Eine DTD für E-Mails und ein XML-Dokument, das auf diese DTD zurückgreift.

Im wesentlichen besteht eine E-Mail aus einem Empfänger, einem Absender, einem Betreff und einer Nachricht. Eine XML-DTD könnte diese vier Elemente so zusammenfassen:

<! DTD fuer E-Mail —></p> <p><!LEMENT email (empfaenger, absender, thema, nachricht)></p> <p><!LEMENT empfaenger (#PCDATA)></p> <p><!LEMENT absender (#PCDATA)></p> <p><!LEMENT betreff (#PCDATA)></p> <p><!LEMENT nachricht (#PCDATA)>

Alle enthalten reinen Text, hier "Parsed Character Data" (PCDATA) genannt.

Eine darauf zurückgreifende E-Mail könnte so aussehen:

<?xml version=(1.0(></p> <p><!OCTYPE email SYSTEM “email.dtd“></p> <p><email></p> <p> <empfaenger>Juergen Fey</empfaenger></p> <p> <absender>Dr.Klaus Schlueter</p> <p> </absender></p> <p> <betreff>Risiken durch XML</p> <p> <\betreff></p> <p> <nachricht></p> <p> Lieber Juergen,</p> <p> ich benoetige Deinen Rat als </p> <p> ausgwiesener Sicherheitsexperte:</p> <p> Inwiefern lassen sich eigentlich</p> <p> über XML trojanische Pferde in ein</p> <p> System einschleusen?</p> <p> Alles Gute,</p> <p> Klaus.</p> <p> </nachricht></p> <p></email>

Natürlich ließe sich das Beispiel beliebig erweitern. Worauf es hier jedoch ankommt ist das modulare Konzept: Weil man immer wieder E-Mails schreibt, macht es Sinn, bestimmte Vereinbarungen auszulagern. Das erleichtert die Arbeit und verringert die Netzlast, falls der Empfänger bereits über eine entsprechende DTD verfügt.

Universeller Datenaustausch

Das World-Wide-Web-Konsortium (W3C) hat XML 1.0 bereits im Februar des vergangenen Jahres verabschiedet. Doch erst Ende 1998 kündigten zahlreiche Firmen ihre Unterstützung von XML auf breiter Front an. Einige Produkte sind bereits auf dem Markt, auch wenn zahlreiche Details noch nicht geklärt sind, etwa die gegenüber HTML erweiterten Links (X-Link, X-Pointer). Insbesondere Microsoft und Netscape wollen die Browser der kommenden Version fünf zuverlässig XML-tauglich machen.

XML eignet sich ideal zum Datenaustausch zwischen unterschiedlichen Systemen. Die neue Markup-Sprache bietet eine höhere Flexibilität als die starren Feldkonzepte relationaler Datenbanken (siehe Kasten "XML Data: Das SQL fürs Web") und ist leistungsfähiger als die Schnittstellenstandards "Common Object Request Broker Architecture" (Corba) und "Distributed Component Object Model" (DCOM). Und selbst wenn als Einsatzgebiet hauptsächlich das Web genannt wird: XML weist deutlich darüber hinaus. Das belegen zahlreiche Beispiele aus der Praxis:

- Chemiker können Moleküle in der "Chemical Markup Language" (CML) beschreiben.

- Verleger können beim Electronic Publishing auf "Open E-Book" setzen.

- Und Finanzleute können mit Banken via "Open Financial Exchange" (OFX) kommunizieren, dem von Intuit Quicken und Microsoft Money benutzten Format.

Alle basieren auf XML und dienen dem Austausch von Daten. Ob Tim Bray wohl diese Vielfalt meinte, als er davon sprach, daß XML nicht die letzte Markup-Sprache sein wird? Jedenfalls warnte er vor proprietären Entwicklungen und ermunterte die Zuhörer, das "Web Standards Project" zu unterstützen: Normen seien für den Konsumenten, nicht für den Verkäufer und ebneten den Weg für einen fairen Wettbewerb. Die Industrie serviere sie jedoch nicht auf einem silbernen Tablett, sondern müsse dazu aufgefordert werden. Deshalb unterstützt auch gateway diese Initiative, über die Sie Näheres unter http://www.webstandards.org erfahren.

Literatur

[1] Behme, H., Mintert, S.: XML in der Praxis – Professionelles Web-Publishing mit der Extensible Markup Language. Addison-Wesley, 1998.

Web-Links

XML:

http://www.w3.org/xml

http://www.xml.com

http://www.sil.org/sgml/xml.html

XMI:

http://www.software.ibm.com/ad/features/xmi.html

Tim Brays Homepage:

http://www.textuality.com/