von Mark Baker

Wir alle wissen, dass XML eine gute Sache ist. Die Experten und die Anbieter sagen uns das. XML eröffnet viele Möglichkeiten für Inhalte. Aber wie (und warum) das so ist, wird nicht immer ganz klar. Wenn Sie Ihren Inhalt in XML übertragen, reicht das allein nicht aus, um einige oder alle versprochenen Dinge zu erreichen. Um zu verstehen, warum das so ist, müssen wir uns ansehen, worum es bei XML wirklich geht.

Ich gehe davon aus, dass Sie die grundlegende Technik von XML kennen und dass Sie Elemente und Merkmale sowie die Tags, die sie definieren, erkennen. Ich nehme deshalb an, dass Sie erkennen, dass das nachstehende Beispiel, das ein Auszug aus einem XHTML-Dokument ist, ein Element <p> und zwei Elemente <i> darin enthält, und dass diese Elemente durch Tags definiert sind, das wiederum sind die Dinge in den eckigen Klammern:

<p><i>Krieg und Frieden</i> ist ein<i>sehr</i> langes Buch.</p>

Diese Tags sind Metadaten. Wenn Menschen über Metadaten sprechen, denken sie oft nur an ein Etikett, das einer Inhaltskomponente angeheftet wird, im Allgemeinen durch ein Content-Management-System, und das genutzt wird, um das Dokument zu verfolgen und es einfacher auffindbar zu machen. Das ist sicherlich eine wichtige Aufgabe von Metadaten, aber sie können noch viel mehr. Metadaten sind Daten, die andere Daten beschreiben. Es gibt viele nützliche Arten von Metadaten, einschließlich XML-Tags. (Mehr darüber erfahren Sie in „The Meaning of Metadata“ (Die Bedeutung von Metadaten)).

XML ist so nützlich, weil es uns ermöglicht, Inhalten jeder Größenordnung Metadaten zuzuordnen, nicht nur einem ganzen Dokument, sondern auch einzelnen Sätze, Wörtern oder Ausdrücken. Im Beispiel oben sagt uns das Tag <i>, dass der Ausdruck „Krieg und Frieden“ kursiv dargestellt werden soll. (Das bedeutet <i> in XHTML. Das Tag <i> kann in anderen Tagging-Sprachen etwas ganz anderes bedeuten.)

Natürlich ist „kursiv darstellen“ nicht die alleranspruchsvollste Art der Aufgaben von Metadaten. Auch scheint es gegen die oft zitierte Regel zu verstoßen, dass XML Inhalt und Formatierung trennt. Tatsächlich ist die oft zitierte Regel falsch. Einige XML-Tagging-Sprachen, beispielsweise XHTML und XSL-FO, wurden speziell dafür entwickelt, Formatierung auf Inhalte anzuwenden. Einige XML-Sprachen wurden dafür entwickelt, den Inhalt von der Formatierung zu trennen. Andere haben mit dem Inhalt gar nichts zu tun. Eine viel bessere Regel würde besagen, dass XML es ermöglicht, Metadaten auf Inhalte anzuwenden, und dass die angewandten Metadaten beinahe alles Gewünschte ausdrücken können.

Also verbindet XHTML Formatierung und Inhalt, und Anwendungen zum Verarbeiten von XHTML (z. B. Webbrowser) würden unseren Mustertext wie folgt ausgeben:

Krieg und Frieden ist ein sehr langes Buch.

Das ist soweit schön, aber mit XML können wir viel mehr erreichen.

 

Trennung von Text und Formatierung

Wenn wir den Inhalt von der Formatierung trennen wollen, müssen wir einige Metadaten hinzufügen, um die Trennung zu erreichen. XHTML ermöglicht es uns, einen ersten Schritt auf diesem Weg zu gehen, indem wir statt des Tags <i> das Tag <em> (Hervorhebung) verwenden:

<p><em>Krieg und Frieden</em> ist ein <em>sehr</em> langes Buch.</p>

Statt festzulegen, dass „Krieg und Frieden“ und „sehr“ kursiv dargestellt werden, besagt dieses Markup nur, dass diese Worte hervorgehoben werden sollen. So können wir es der Verarbeitungsanwendung überlassen zu entscheiden, wie die Worte hervorgehoben werden. Beispielsweise könnte sie folgendes tun:

Krieg und Frieden ist ein sehr langes Buch.

Aber dabei gibt es ein Problem. Die Verarbeitungsanwendung hat jedes Recht der Welt, den hervorgehobenen Inhalt fett und rot zu drucken, denn fetter roter Text ist auf jeden Fall hervorgehoben. Aber es gibt Konventionen für das Darstellen von Buchtiteln, und die Konvention besagt, dass Buchtitel kursiv ausgegeben werden.

Wenn wir den Inhalt von der Formatierung trennen, sollten wir es also richtig tun. Wenn wir <em> nur als Synonym für <i> nutzen, dann trennen wir den Inhalt nicht von der Formatierung, und wir sollten in diesem Fall bei <i> bleiben, denn es ist die bessere Möglichkeit zu sagen, was wir meinen.

Wenn wir den Inhalt wirklich von der Formatierung trennen wollen, sollten wir besser einen deutlicheren Weg finden, als nur einfach überall <i> durch <em> zu ersetzen. Wenn wir den Text nicht direkt formatieren, müssen wir der Verarbeitungsanwendung so viele Metadaten geben, dass sie Dinge unterscheiden kann, die unterschiedlich formatiert werden sollen.

Um der Verarbeitungsanwendung genügend Informationen zum korrekten Formatieren von „Krieg und Frieden“ zu geben, müssen wir Metadaten bereitstellen, die besagen, dass der Ausdruck „Krieg und Frieden“ ein Titel ist:

<p><title>Krieg und Frieden</title> ist ein <em>sehr</em> langes Buch.</p>

Jetzt haben wir ausreichend Informationen bereitgestellt, so dass der XML-Prozessor den Text entsprechend ausgeben kann:

Krieg und Frieden ist ein sehr langes Buch.

Als wir unserer Tagging-Sprache jedoch das Tag <title> hinzugefügt haben, haben wir uns von XHTML fortbewegt. XHTML unterstützt ein Tag mit der Bezeichnung <title>, aber es verwendet dieses Tag innerhalb des Elements <head>, um den Titel des aktuellen Dokuments zu erfassen. Es unterstützt die Verwendung von <title> innerhalb des Elements <p> zum Kennzeichnen von Buchtiteln nicht. Aber wenn wir nicht mehr XHTML verwenden, was dann? Wir verwenden jetzt eine Tagging-Sprache, die wir selbst erfunden haben. Ich nenne sie YAMLX (Yet Another Markup Language eXample, schon wieder ein Beispiel für Markup-Sprachen). Wir beginnen, Metadaten zu erfassen, die wichtig für unser Unternehmen sind. Das bedeutet, dass wir angefangen haben, die Verantwortung für unser eigenen Markup-Design zu übernehmen, und entweder eine bestehende Markup-Sprache finden, die die von uns benötigten Metadaten enthält, oder selbst eine erschaffen. Für den Zweck dieses Artikels ist es unwichtig, ob YAMLX eine öffentlich verfügbare oder eine Sprache ist, die Sie selbst kreieren. Wichtig ist, dass YAMLX die Metadaten erfasst, die Sie benötigen, damit Ihr Inhaltsprozess effizient läuft.

Natürlich werden Webbrowser das nicht direkt verstehen, da YAMLX nicht XHTML ist. Um zu veröffentlichen, müssen Sie die Sprache verarbeiten, so dass die Browser wissen, wie diese auszugeben ist. Dafür gibt es mehrere Möglichkeiten. Eine Möglichkeit besteht darin, eine CSS-Stilvorlage zu erstellen, um dem Browser zu sagen, wie YAMLX-Elemente dargestellt werden, eine weitere ist es, ein XSLT-Skript  zu erstellen, um YAMLX in HTML umzuwandeln. Einige der Dinge, die wir später zu YAMLX hinzufügen werden, werden uns in die Richtung von XSLT bringen, also werden wir uns diese Sprache hier ansehen.

Glücklicherweise unterscheidet sich YAMLX (bisher) nur in einem Tag von XHTML, also können wir eine XSLT-Vorlage schreiben, um ein Element <title> innerhalb des Elements <p> zu einem gültigen XHTML-Tag zu machen und den Rest einfach zu kopieren. Dies ist die Vorlage, die das Element <title> in ein Element <i> umwandelt:

<xsl:template match=”p/title”>
<i>
<xsl:apply-templates/>
</i>
</xsl:template>

Lassen Sie sich von dieser Markup-Sprache nicht verwirren. Sie ist ganz einfach. Sie sagt dem Ausgabemodul für Inhalte, dass es Elemente <title> innerhalb von <p> durch <i> ersetzen soll. Es ist unwichtig, ob Sie genau verstehen, wie es funktioniert, aber wie Sie sehen, ist es keine Astrophysik.

 

Semantisches Markup

Gut, wir haben also den Text von der Formatierung getrennt und zwischen Titeln und allgemeiner Hervorhebung unterschieden, so dass sie unterschiedlich formatiert werden können. Aber wir können mit diesem Markup wirklich nur die Formatierung kennzeichnen. Das Trennen von Inhalt und Formatierung steigert die Produktivität nicht ins Unendliche, wenn man beides danach einfach wieder zusammenfügt. Um einen Vorteil aus der Trennung zu ziehen, müssen wir mehr tun. Aktualisieren wir also YAMLX, so dass es einigere nützlichere Metadaten erfasst:

<p><title isbn=”1400079985″>Krieg und Frieden</title>ist ein <em>sehr</em> langes Buch.</p>

Hier haben wir dem Tag <title> in Form eines Merkmals isbn einige Metadaten hinzugefügt: Mit diesen zusätzlichen Metadaten identifiziert die Sprache „Krieg und Frieden“ nicht nur als Titel, sondern als den Titel des Werks.

Was können wir mit diesen zusätzlichen Metadaten anfangen? Die ISBN-Nummer ist der Schlüssel zu vielen Daten über ein veröffentlichtes Buch. Wenn wir die ISBN-Nummer haben, können wir viele andere Informationen  nachschlagen. Beispielsweise können wir die ISBN nutzen, um über einen Webservice wie ISBNdb  Details zur Veröffentlichung abzufragen.

Die meisten Webservices geben Informationen in XML aus, was für uns ideal ist, da unser Inhalt in XML vorliegt. Ein hypothetischer ISBN-Webservice könnte ein XML-Dokument zurückschicken, das wie folgendes aussieht (das Dargestellte wird nicht von ISBNdb zurückgeschickt, es ist nur ein vereinfachtes Beispiel):

<book>
<isbn>1400079985</isbn>
<title>Krieg und Frieden</title>
<author>Leo Tolstoi</author>
<publisher>Vintage</publisher>
<publication-year>2008</publication-year>
<page-count>1296</page-count>
…
</book>

Wir könnten dann Stücke aus dem XML-Dokument ziehen, die wir unserem eigenen Inhalt hinzufügen, was es uns ermöglicht, Inhalte wie den folgenden herzustellen:

Krieg und Frieden (Leo Tolstoi, Vintage, 2008, 1296 Seiten) ist ein sehr langes Buch.

Natürlich tun wir das nicht von Hand. Wir benutzen dafür ein Skript. Nur um zu zeigen, dass auch das keine Astrophysik ist, sehen Sie hier einen Schnipsel des XSLT-Codes, der das durchführt:

<xsl:template match=”p/title”>
<!– capture the isbn number to look up –>
<xsl:variable name=”isbn” select=”@isbn”/>

<!– call the web service to get book info using the isbn –>
<xsl:variable name=”book-info” select=”document(concat(‘http://example.com/isbn/lookup?’, $isbn))”/>

<!– output the book title –>
<i>
<xsl:apply-templates/>
</i>

<!– output the additional book info –>
<xsl:text> (<xsl:text>
<xsl:value-of select=”$book-info/book/author”/>
<xsl:text>, <xsl:text>
<xsl:value-of select=”$book-info/book/publisher”/>
<xsl:text>, <xsl:text>
<xsl:value-of select=”$book-info/book/publication-year”/>
<xsl:text>, <xsl:text>
<xsl:value-of select=”$book-info/book/page-count”/>
<xsl:text>) <xsl:text>
</xsl:template>

 

Auch das ist keine Astrophysik, aber diese einfache Technik öffnet Türen aller Art. Die Informationen zur Publikation waren nicht im ursprünglichen XML enthalten. Sie wurden über im XML erfasste Metadaten aus einer anderen Quelle abgefragt. Die Fähigkeiten des semantischen Markup, das Zusammenführen von Informationen aus unterschiedlichen Quellen zu ermöglichen, ist enorm. Hier sehen Sie nur einige wenige der Tricks, die wir mit den durch die ISBN-Nummer abgefragten Informationen durchführen könnten:

• Einbeziehen eines Einbandbilds
• Erstellen eines Links zu einem Artikel über „Krieg und Frieden“ auf unserer Webseite
• Erstellen eines Links zu einem Online-Buchladen, in dem der Leser das Buch kaufen kann Wenn Sie an einem Partnerprogramm eines Online-Buchladens teilnehmen würden, könnten Sie jedes Mal, wenn ein Leser Ihrem Link folgt und ein Buch kauft, etwas Geld verdienen. Jetzt haben die Metadaten der ISBN-Nummer aus einem beiläufigen Verweis eine potenzielle Einnahmequelle gemacht.

 

Autoren effizienter machen

Es gibt auch größere Prozesseffizienzen, die durch das Abfragen von Metadaten dieser Art in Ihrem XML-Inhalt umgesetzt werden können. Wenn Sie Metadaten-Schlüssel nutzen können, um Informationen aus externen Quellen abzufragen, brauchen die Autoren die Informationen beim Schreiben nicht selbst nachzuschlagen. Sie müssen nicht entscheiden, welche der Details zum Buch in der endgültigen Ausgabe erscheinen. Diese Entscheidung erfolgt durch das Bearbeiten der XSLT-Stilvorlage, und sie kann für alle vorhandenen Inhalte verändert werden, indem man einfach die Stilvorlage verändert.

Wie Sie sehen, können wir beim Verfassen viel Zeit sparen, wenn wir einfach Metadaten in unser XML einfügen, und dennoch bleiben alle Optionen, darüber zu entscheiden, welche Details veröffentlicht werden, offen. Wenn es sich um große Inhaltssätze handelt, können diese Effizienz und diese Flexibilität zu beträchtlichen Kosteneinsparungen und höheren Umsätzen führen.

Weiteres Verfeinern der Metadaten

Obwohl wir durch das Berücksichtigen der ISBN-Nummer in YAMLX viele Optionen erhalten, gibt es bei diesem Markup einige Probleme.

Das erste Problem ist die Genauigkeit der Metadaten. Die ISBN-Nummer identifiziert das Werk nicht direkt. Sie identifiziert eine bestimmte Ausgabe des Buchs von einem bestimmten Verlag in einer bestimmten Bindung in einem bestimmten Jahr. Diese Unterscheidung kann wichtig sein. Es gibt viele andere Ausgaben  von „Krieg und Frieden“ in vielen Sprachen. „Krieg und Frieden“ ist in all diesen Ausgaben und all diesen Sprachen ein sehr langes Buch. Der Abschnitt bezieht sich nicht speziell auf die Vintage Edition von 2008. Er bezieht sich auf „Krieg und Frieden“ als Roman im Allgemeinen. Durch die Nutzung der ISBN-Nummer werden die Metadaten tatsächlich spezifischer als der Text sie kennzeichnet. Das könnte für einige der Arten, auf die wir diesen Inhalt möglicherweise abfragen wollen, ein Problem darstellen.

Nehmen wir an, wir wollten in unserem Inhalt eines Liste aller Aussagen über den Roman „Krieg und Frieden“ haben. Das können wir sehr einfach mit einem XPath -Ausdruck wie diesem erreichen:

p[title="Krieg und Frieden"]

Das besagt, dass alle Elemente <p> angezeigt werden sollen, die ein Element <title> mit dem Inhalt „Krieg und Frieden“ enthalten. Noch einmal, machen Sie sich keine Gedanken um die Syntax. Ich zeige Ihnen das nur, um Ihnen zu demonstrieren, dass nichts davon wirklich schwierig ist.

Es gibt jedoch ein Problem mit diesem XPath-Ausdruck. Er wird alle Abschnitte ausgeben, die einen Titel „Krieg und Frieden“ enthalten. Aber darin könnten Verweise auf den Titel des Films  mit diesem Namen, auf die Oper  oder auf das Sachbuch namens „Krieg und Frieden“ enthalten sein, und das wollen wir nicht. Wir wollen nur Aussagen über den Roman.

Um die Suche auf den Roman einzugrenzen, suchen wir nach weiteren Metadaten, die uns helfen, den Fokus zu verengen. Die ISBN gehört zu diesen Metadaten, also können wir folgendes versuchen:

p[title/@isbn="1400079985"]

Das besagt, dass alle Elemente <p> angezeigt werden sollen, die ein Element <title> mit einem Merkmal ISBN enthalten, das einen Wert von „1400079985“ hat. Damit werden sicher alle Filme, Opern und Sachbücher entfernt, aber wir könnten auch einige Verweise auf den Roman verlieren. Das Problem ist, dass es mehrere ISBN-Nummern gibt, die sich auf den Roman Krieg und Frieden beziehen, da er in vielen unterschiedlichen Ausgaben vorliegt. Nicht alle Autoren, die einen Verweis auf Krieg und Frieden kennzeichnen, schlagen unter derselben ISBN nach. Und deshalb ist es ein Problem, dass unsere Metadaten spezifischer als der Kontext sind, den sie beschreiben: es kann dazu führen, dass wir Teile des Inhalts verlieren.

Ein zweites Problem ist die Produktivität des Autors. Der Autor, der den Abschnitt geschrieben hat, kennt wahrscheinlich keine ISBN einer bestimmten Ausgabe von Krieg und Frieden auswendig. Wenn das Markup eine ISBN benötigt, muss der Autor pausieren und eine ISBN nachschlagen. Wenn man es den Autoren erspart, eine Pause einzulegen und Dinge nachzuschlagen, bringt das möglicherweise bedeutende Vorteile für die Produktivität mit sich. Es kann auch potenziell unseren Pool verfügbarer Autoren vergrößern.

Wenn man also die ISBN für die Metadaten verwendet, ist das zu genau und erschwert das Leben der Autoren. Wir brauchen ein Markup, das genau die richtige Präzisionsebene darstellt und für die Autoren einfacher zu erstellen ist. Wir könnten beispielsweise Folgendes tun:

<p><novel author=”Leo Tolstoi”>Krieg und Frieden</novel> ist ein <em>sehr</em> langes Buch.</p>

Hier haben wir das Tag <title> durch das spezifischere Tag <novel> und das zu spezifische Merkmal ISBN durch das perfekte Merkmal Autor ersetzt (nur für den Fall, dass noch ein anderer Autor einen Roman namens Krieg und Frieden geschrieben hat).

Diese Kennzeichnung ist für die Autoren offensichtlich einfacher zu erstellen. Es fragt nur nach Dingen, die sie bereits wissen, also müssen sie beim Schreiben nicht zwischendurch etwas nachschlagen.

Wie sieht es damit aus, alle Abschnitte auszuwählen, die sich auf den Roman von Tolstoi beziehen? Wir können auch das genauer schaffen, wenn wir einen XPath-Ausdruck wie den folgenden benutzen:

p[novel[@author="Leo Tolstoi"] = “Krieg und Frieden”]

Das besagt, dass alle Elemente <p> angezeigt werden sollen, die ein Element <novel> mit einem Merkmal Autor mit dem Wert „Leo Tolstoi“ und einen Inhalt „Krieg und Frieden“ enthalten. Das ist genau das, was wir wollten, also haben wir anscheinend jetzt korrekte Metadaten.

Wirklich? Mit den ISBN-Metadaten konnten wir Informationen zu Publikationen abfragen, indem wir die ISBN-Nummer nutzten, um die ISBN-Datenbank abzufragen. Wie bekommen wir diese Daten ohne die ISBN-Nummer? Wir können diese Daten immer noch bekommen, aber wir müssen eine andere Abfrage verwenden, um sie zu extrahieren. In unserer ursprünglichen Programmierung sah das Markup wie folgt aus:

<xsl:variable name=”book-info” select=”document(concat(‘http://beispiel.com/isbn/lookup?’, $isbn))”/>

Jetzt müssen wir es verändern, damit es die Daten aufgrund unserer Metadaten abfragt: Kategorie (Roman), Titel und Autor:

<xsl:template match=”p/novel”>
<!– capture the metadata to look up –>
<xsl:variable name=”title” select=”.”/>
<xsl:variable name=”author” select=”@author”/>

<!– call the web service to get book info –>

<xsl:variable name=”book-info” select=”document(concat(‘http://Beispiel.com/isbn/lookup?category=novel&title=’, $title, ‘&author=’, $author))”/>

Der einzige Unterschied bei den Ergebnissen dieser Abfrage ist, dass es wahrscheinlich mehrere Bücher mit dieser ISBN gibt (es ist ganz sicher so, denn es gibt viele Druckausgaben von Krieg und Frieden). Also muss der Code, der dem Inhalt die Informationen zum Buch hinzufügt, basierend auf den Daten der Veröffentlichung (z. B. jüngstes Veröffentlichungsdatum) einige der Alternativen auswählen. Ein zusätzlicher Vorteil besteht darin, dass die angezeigten Informationen einheitlich sind, wann immer wir uns in unserem Inhalt auf Krieg und Frieden beziehen.

Sollten wir also „Krieg und Frieden“ immer mit dem Tag <novel> und dem Merkmal „Autor“ versehen? Nicht unbedingt. Wir sehen hier, dass wir uns, wenn wir in unserem Inhalt „Krieg und Frieden“ erwähnen, auf unterschiedliche Dinge beziehen könnten. Wir könnten, wie in dem hier vorliegenden Fall, über den Roman im Allgemeinen sprechen. Aber unter anderen Umständen könnten wir uns auf eine bestimmte Ausgabe des Romans beziehen. Obwohl der Ausdruck in beiden Fällen „Krieg und Frieden“ ist, bezieht sich der Text auf unterschiedliche Dinge. Eine der wichtigsten Aufgaben von XML-basierten Metadaten ist es, diese Art von Unterscheidung klarzustellen, so dass wir die Fälle unterschiedlich behandeln können.

Wir benötigen in YAMLX tatsächlich zwei unterschiedliche Tags, so dass wir die richtigen Metadaten auf die Worte „Krieg und Frieden“ anwenden können, je nachdem, was sie im jeweiligen Fall bedeuten. Bei Verweisen auf den Roman könnten wir schreiben:

<p><novel author=”Leo Tolstoi”>Krieg und Frieden</novel> ist ein <em>sehr</em> langes Buch.</p>

Für Verweise auf eine bestimmte Ausgabe des Romans könnten wir YAMLX um ein Element für die Ausgabe erweitern, das das Merkmal „ISBN“ aufweist:

<p><edition isbn=”1400079985″>Krieg und Frieden</title>ist <em>immer noch</em> nicht auf Lager.</p>

Jetzt kann unsere Verarbeitungsanwendung erkennen, dass die Worte jeweils etwas anderes bedeuten, und sie entsprechend verarbeiten.

 

Wer das Datenformat beherrscht, beherrscht die Funktionalität

Welches Tag ist also am besten geeignet, um die Worte „Krieg und Frieden“ zu kennzeichnen ‒ <i>, <em>, <title>, <novel> oder <book>? Es gibt keine richtige Antwort. Es hängt immer davon ab, was Sie mit Ihren Daten erreichen wollen. Inhalte sind Daten. Inhalte werden zu Daten, sobald man sie in ein Computersystem eingibt. Ob es sich um ein Microsoft Word Dokument, um eine Adobe FrameMaker  Datei oder um XML handelt, Inhalte sind Daten. Der Unterschied ist, dass Sie bei XML die Struktur Ihrer eigenen Inhaltsdaten besitzen.

Es ist wichtig, die Datenstruktur Ihrer Inhalte zu beherrschen, denn wenn man diese Struktur beherrscht, hat man die Kontrolle über die Funktionen zum Erstellen und Veröffentlichen von Inhalten. Wenn Sie ein binäres Format wie Word oder FrameMaker verwenden, erhalten Sie die Funktionen von Word oder FrameMaker. Mit etwas Skripting-Aufwand können Sie einige Funktionen hinzufügen, aber nur soweit das Datenmodell von Word oder FrameMaker dies zulässt. Bei XML entscheiden Sie über das Dateiformat, und Sie entscheiden, welche Funktionen Sie implementieren, um Ihre Daten zu verarbeiten. Sie können das Datenformat definieren, das Ihren spezifischen Unternehmensanforderungen am besten entspricht.

Das bedeutet jedoch alles nicht viel, sofern Sie Ihre Daten nicht auf eine Art nutzen, die Sie mit Word oder FrameMaker nicht erreicht hätten ‒ z. B. das automatische Einfügen zusätzlicher Inhalte aus einer Datenbank, um Ihre Inhalte zu erweitern und Ihren Autoren Arbeit zu sparen.

Der echte Vorteil hierbei liegt darin, dass Ihre Inhalte durch XML zu einer Datenbank werden. Weil XML es Ihnen ermöglicht, Metadaten auf Inhalte jeder Größenordnung anzuwenden, können Sie Ihre Inhalte in jeder Größenordnung abfragen und verarbeiten. Gleichzeitig können Sie Metadaten in Ihre Inhalte einbetten, die Sie nutzen können, um eine Datenbankabfrage zu erstellen, die andere Daten einspeist (wie wir es am Beispiel der ISBN gesehen haben).

Und das ist die Aufgabe aller XML-Tagging-Sprachen ‒ Inhalte in Datenbanken umzuwandeln. Der Unterschied zwischen den einzelnen XML-Sprachen besteht darin, wie detailliert und spezifisch die Strukturen der jeweiligen Datenbank sind und wie gut sie auf bestimmte geschäftliche Anforderungen abgestimmt sind. Das hat wirklich wichtige Folgen, unabhängig davon, ob Sie nach einem Automatisierungssystem suchen oder ein eigenes aufbauen: Das Datenformat ist wichtiger als die Anwendungsfunktion.

Wenn Sie ein herkömmliches betriebsbereites Werkzeug wie Word oder FrameMaker kaufen, basiert Ihre Kaufentscheidung größtenteils auf den Funktionen der Anwendung. Sie achten nicht darauf, was sie in Zukunft leisten könnte, sondern darauf, was sie heute kann. Darüber, wie das Dateiformat der Anwendung ihre Funktionen unterstützt, machen Sie sich im Allgemeinen keine Gedanken. Sie kaufen die Funktion, nicht die Datenstruktur.

Aber bei XML sollten Sie nicht zuerst überlegen, welche Funktionen mitgeliefert werden, sondern welche Funktionen die Datenstruktur des XML-Formats unterstützt. Auch wenn Sie ein Werkzeug oder ein Werkzeug-Kit mit bestehenden Funktionen nutzen, sind Sie nicht auf diese Funktionen beschränkt, und sie sollten nicht der Hauptgrund für Ihre Entscheidung sein. Wenn sie von Ihrer Datenstruktur unterstützt werden, können Sie immer alle benötigten Funktionen hinzufügen. Aber Sie können keine Funktionen kaufen oder aufbauen, die die Daten nicht unterstützen.

Das sollten Sie also wissen, wenn Sie eine XML-Lösung in Betracht ziehen:

• Durch XML werden Ihre Inhalte zu einer Datenbank. Sie können diese Datenbank abfragen, um Ihre Inhalte zu organisieren und zu strukturieren oder um Inhalte aus unterschiedlichen Quellen zu kombinieren.
• Das Design der Datenbank legt fest, wie Sie die Daten nutzen können. Sie müssen sorgfältig auf das Design Ihres Markups achten, um sicherzustellen, dass Sie die Funktionen implementieren können, die Sie benötigen, um den Prozess der Inhaltsentwicklung zu optimieren.
• Sie können die Produktivität der Autoren steigern und mehr Autoren mitarbeiten lassen, indem Sie das Markup so gestalten, dass Informationen abgefragt werden, die die Autoren bereits kennen, und dann diese Informationen nutzen, um damit verknüpfte Daten abzufragen.
• Ihre wichtigste Entscheidung besteht nicht darin, welche Funktionen ein bestimmtes Tool sofort unterstützt, sondern welche Funktionen das Format Ihrer Inhalte unterstützen wird.

 

Über den Autor

Mark Baker, President von Analecta Communications Inc., besitzt über 20 Jahre Erfahrung in der Branche der technischen Kommunikation und über 15 Jahre Erfahrung bei der Gestaltung, Implementierung und Nutzung von Systemen für das strukturierte Authoring. Er schreibt ein Blog auf everypageispageone.com.