1.3 Wohin die Reise geht

Otto Web-Normalverbrauchers Homepage wird auf lange Sicht in HTML geschrieben sein. So äußerten sich die Experten noch im April 1997; und sie dürften Recht behalten. Für eine Homepage oder zwei, drei Seiten für Freunde und Verwandte lohnt sich der Aufwand, XML zu lernen, nichtIn Form von XHTML werden es Webautoren mittelfristig auf jeden Fall mit einer XML-Anwendung zu tun bekommen.. Deswegen richtet sich dieses Buch eher an diejenigen, die HTML kennen und bislang schon intensiv damit gearbeitet haben oder planen, das demnächst zu tun.

Manchem dürfte XML, vor allem wenn es um die Erstellung der eingangs genannten DTDs geht, wie die scheinbare Unlesbarkeit des Mottos vorkommen. In beiden Fällen gilt: Iss up 2 u reely whot yoos u make ov it aftir that; iss ol about injinooty. Im Ernst: XML ist keine Auszeichnungssprache wie HTML. Als Teilmenge von SGMLDen Fachmann wird's zwar nerven, aber gerade in diesem Kapitel kann man nicht oft genug darauf hinweisen. ist es eben eine Spezifikation für die Schaffung beliebig vieler Auszeichnungssprachen. Einige Beispiele solcher Sprachen kommen in diesem Buch vor, und sie sind einfacher nachzuvollziehen als die allseits bekannte Web-Sprache.

Sich Sprachen auszudenken, macht bereits kleinen Kindern Spaß. Und trotz des ernsten Hintergrunds — schließlich lernt man komplexe Dinge nicht zum Spaß — glauben wir, dass XML gerade durch sein X (die Erweiterbarkeit) Spaß machen kann und wird.

Dahin zu gelangen, erfordert Lesearbeit. Das vorliegende Buch soll nicht nur die Grundlage dafür bieten; es soll selbstverständlich auch als Nachschlagewerk dienen und zum Schmökern in den Beispielen einladen.

Wer mit XML arbeiten will, demJa, auch der ... ;-) stehen sowohl kostenlose als auch kommerziell vertriebene Produkte zur Verfügung (siehe Kapitel 12). Unter http://www.heise.de/ix/raven/Web/xml/ finden Sie eine — sicherlich unvollständige — Liste frei erhältlicher Software. Es handelt sich um Editoren und Parser sowie Tools für die Erstellung und Verarbeitung von Stylesheets beziehungsweise das Generieren von Daten (HTML, RTF).

Natürlich dürfen hier die zehn Aussagen nicht fehlen, die in der Syntaxbeschreibung von XML umreißen, worum es den Entwicklern der Sprache geht und ging:

1. XML soll sich im Internet auf einfache Weise nutzen lassen.
2. XML soll ein breites Spektrum von Anwendungen unterstützen.
3. XML soll zu SGML kompatibel sein.
4. Es soll einfach sein, Programme zu schreiben, die XML-Dokumente verarbeiten.
5. Die Anzahl optionaler Merkmale in XML soll minimal sein, idealerweise Null.
6. XML-Dokumente sollten für Menschen lesbar und angemessen verständlich sein.
7. Der XML-Entwurf sollte zügig abgefasst werden.
8. Der Entwurf von XML soll formal und präzise sein.
9. XML-Dokumente sollen leicht zu erstellen sein.
10. Knappheit von XML-Markup ist von minimaler Bedeutung.

Die meisten dieser Design-Ziele hängen zusammen, etwa das zweite und dritte: weil SGML eben eine Vielfalt von Anwendungen unterstützt. Nur das letzte Ziel bringt Sie vielleicht zum Schmunzeln. Knappheit in der Auszeichnung (terseness in markup) ist deshalb nicht erstrebenswert, weil Maschinen nun einmal Mengendaten gut verarbeiten können. Es soll sich zwar um für Menschen lesbare Dokumente handeln, aber für Rechner, die letztlich die Verarbeitung erledigen sollen, ist es völlig unerheblich, wie ausführlich (oder umständlich) die Quelltexte sind. Ein kleines Code-Beispiel (das einzige in diesem Kapitel) zeigt, was gemeint ist:

<mitarbeiter id="firma.abteilung.4725721.r238-4523/003"
        eintritt="01011976"
        lastmod="04021997"
        lastmodby="firma.abteilung.31296.261263c-3461/001">
    <name>Meier</name>
    <vorname>Heinz</vorname>
    <gebdatum>
          <jahr>1938</jahr>
          <monat>10</monat>
          <tag>29</tag>
    </gebdatum>
<!-- viele weitere Daten -->
</mitarbeiter> 
        

Ohne jetzt schon in Erklärungen abzuschweifen: Das Beispiel riecht förmlich nach Datenbanken, und das ist kein Zufall. Ein beträchtlicher Anteil der künftig im Web abzurufenden Daten (sofern sie in XML vorliegen) dürfte aus Datenbeständen generiert sein. Das hat verschiedene Gründe. Erstens ist die sequenzielle Generierung großer Datenbestände aus einer Datenbank am sinnvollsten (Konsistenz et cetera), zweitens gilt: Habe ich aus einem Datensatz korrektes XML generiert, dann funktioniert das auch mit Hunderttausenden.

Drittens müssen die resultierenden Dokumente nicht unbedingt XML-Instanzen sein. Es kann sich — und wird es in vielen Fällen sein — um in HTML gewandelte Ausschnitte (in der Sprache der Datenbänker: Views oder Sichten) handeln. Einfachstes Beispiel ist das Inhaltsverzeichnis dieses Buches, das im Quelltext so gar nicht bestand, sondern automatisch erstellt wurde.

Zum besseren im Sinne von erfolgreicheren Arbeiten mit XML hier ein paar Zusätze in Form von Geboten, an die jede(r) sich beim Verfassen oder Generieren von XML-Dokumenten halten sollte.

1. Du sollst Deine Elemente immer schließen.
2. Du sollst Attributwerte immer in doppelte Anführungszeichen setzen.
3. Schachtele Deine Elemente immer hierarchisch.

Wer dies beachtet, den loben die Parser. Etwas ausführlicher lassen die Gebote sich etwa so umschreiben: Alle Elemente zu schließen, heißt im Normalfall, dass jede Elementinstanz außer dem Start-Tag auch ein End-Tag haben muss:

<mein-elem attribut="wert">Inhalt von 
mein-elem</mein-elem>

Das dürfte vor allem für diejenigen gewöhnungsbedürftig sein, die sich bislang darauf verlassen haben (und dies auch tun konnten), dass die Browser selbst herausfinden, wo ein Element aufhört und eine neues beginnt.

Eine Ausnahme gibt es auch von dieser Regel: Das leere Element (IMG aus der HTML-DTD wäre ein Beispiel) kann, muss aber nicht mit einem End-Tag abgeschlossen werden. Zusätzlich erlaubt die Spezifikation — anders als in HTML — eine weitere Schreibweise, den Schrägstrich vor der schließenden spitzen Klammer:

<abbildung src="bildquelle" text="bild-kommentar" />
<abbildung src="bildquelle" text="bild-kommentar"></abbildung>        

Was in HTML durch die Großzügigkeit der DTD möglich ist, nämlich End-Tags wegzulassen, das funktioniert in XML nicht. Jedes Element muss ordentlich abgeschlossen sein.

Die zweite Vorgabe ist insofern neu, als es in HTML zwar als guter Stil gilt, Attribute mit Anführungszeichen zu versehen:

<body bgcolor="#ffffff" text="#000000">

Eigentlich sind sie aber nicht erforderlich. Browser wie der Internet Explorer oder der Navigator sind auf jeden Fall einverstanden, wenn jemand die Zeichen weglässt. Das Gleiche gilt im Prinzip für das dritte Gebot, denn HTML sieht die hierarchische Schachtelung von Elementen durchaus vor. Es sind die Browser, die über Zeilen wie

<p>Beispiel: <b>fetter und 
<i>kursiver</b> Text</i> 
ab hier normal</p>

Abbildung 2: Navigator 4.04 stellt das letzte Listing wie diese Abbildung dar.

gnädig hinweggehen. In XML-Dokumenten ist strenger als in HTML darauf zu achten, dass die Elemente korrekt geschachtelt sindNoch einmal zum Grund dafür: Es gibt in XML keine Tag-Minimierung, das heißt, man darf keine End-Tags weglassen.. In den meisten Fällen wird's der Editor schon richten ... Dennoch ist es gut, sich daran zu gewöhnen, dass diese strikte Ordnung in XML wichtig ist, weil sie bereits in der Planungsphase berücksichtigt werden kann und zur sinnvollen Struktur von DTD (die die hierarchische Ordnung vorgibt beziehungsweise beschreibt) und Dokumenten beiträgt.

Disziplin hin und her: XML verspricht vielleicht keine Lösung aller durch proprietäre Formate bestehenden Konvertierungsprobleme, aber mindestens die Freude, aus einer selbst entwickelten Struktur und entsprechend ausgezeichneten Dokumenten (sowie ein paar dazugehörigen Stylesheets) Web-Dokumente zu generieren, die gut zu warten sind. Das Management einer Website etwa lässt sich durch die zentrale Verwaltung von Links (beispielsweise Sites mit vielen Seiten, die viele Links enthalten) wesentlich vereinfachen, um nur ein einfaches Beispiel zu nennen.

Außerdem ist es unsere Hoffnung, dass der Umgang mit XML kreativen Web-Autoren sogar schon für sich Spaß macht, denn wenn man die ersten Hürden überwunden hat (eine DTD zu schreiben), dürfte schnell klar sein, wo die Vorteile gegenüber HTML liegen.

Ein abschließender Satz darf in dieser Einführung nicht fehlen: Wenn Sie dieses Buch lesen, wird manches, das hier steht, leider schon veraltet sein. Das gilt für erhältliche Software ebenso wie für den Stand der Dinge beim W3C. Die Spezifikation für das Linking und Entwürfe für die Stilkomponente dürften noch in diesem Jahr fertig werden.