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.

Am besten beginnt man dort, wo es schmerzt.

Einführung des Datenbank-Publishing

In einem Unternehmen fanden wir eine kleine Gruppe, die in einem sehr langsamen, kostenaufwendigen und mühsamen Prozess Produktkataloge und Preislisten für die Händler zusammenstellte. Die grundlegenden Produktbeschreibungen und die Aufstellungen der Vorteile wurden mit Fotos der einzelnen Produkte und Datentabellen kombiniert, die manuell aus den Preisdaten der Preisdatenbank des Unternehmens kopiert worden waren. Nachdem der Text zusammengestellt und freigegeben worden war, benötigte ein Grafikdesigner mit Adobe InDesign sechs Monate, um sorgfältig das Layout für jede einzelne Seite zu gestalten. Als der Katalog schließlich fertiggestellt war, waren die Preisdaten bereits veraltet. Jeder Katalog war eine chaotische Mischung von Seitenlayouts mit Sternen, Balken, Explosionen und anderen „dekorativen“ Objekten, die über Hunderte einzelner Seiten verstreut waren. Das Designchaos erschwerte es, den Inhalt in letzter Minute mit den Änderungen zu aktualisieren. Und für die Kunden war es schwierig, genau die richtigen Produkte und Preise zu finden.

Abbildung 1: Der vorhandene Prozess der Katalogentwicklung

Der dynamische Entwicklungsprozess

Wie bewältigen Sie also die Herausforderungen der herkömmlichen Produktkataloge? Identifizieren Sie zunächst die gemeinsamen Elemente des Katalogtexts und helfen Sie dem Katalogteam, einen Standard zu entwickeln. Die Loyalität dem Layoutchaos gegenüber zu überwinden, bedeutet, das Potenzial für Kosteneinsparungen auszureizen. Das Versprechen einer schnelleren Umsetzung und geringerer Entwicklungskosten wird auch das widerspenstigste Vertriebsteam von den Vorteilen standardisierter Texte überzeugen.

Als nächstes kommt das Design einer vereinfachten Authoring-Umgebung. Der Standardtext besteht aus einem Produktnamen, einer kurzen Beschreibung und einer Liste der Vorteile. Alle Produkte werden mit einem oder zwei Fotos illustriert. Das Ergebnis ist ein durchgängig einfaches Design, das mit Leichtigkeit von einem einzigen Autoren entwickelt werden könnte.

Die Grundlage für das Verfassen wird ein Tool zur Bearbeitung von XML/DITA, das das Eingeben von Inhalten vereinfacht. Alle Produktbeschreibungen entsprechen genau derselben Struktur, ein Merkmal, das den Zugang zu den Inhalten und die Lesbarkeit für die Kunden steigert.

[Anmerkung des Redakteurs: DITA bezieht sich auf die Darwin Information Typing Architecture (Darwin-Architektur zum Eingeben von Informationen), eine XML-basierte Architektur zum Verfassen, Erstellen und Ausgeben technischer Inhalte. XML steht für Extensible Markup Language (erweiterbare Kennzeichnungssprache), ein Set mit Regeln zum Programmieren von Dokumenten in einem Format, das sowohl Menschen als auch Maschinen lesen können.]

Der schwierigste Teil des neuen Prozesses ist das Gestalten eines Vorgangs zum Erstellen der Preistabellen, in dem die Daten direkt aus der Finanzdatenbank eingespeist werden. Sobald die erforderlichen Umwandlungen eingerichtet sind, werden die Tabellen automatisch aufgebaut und im DITA-Thema an den Inhalt angehängt.

Für dieses Projekt haben wir Transformationen erstellt, um benutzerspezifische Indizes zu entwickeln, damit die Händler die Informationen einfacher finden können. Nachdem die Stilvorlage XSL-FO eingerichtet war, konnte ein Design- und Publishing-Prozess, der sonst Monate dauerte, innerhalb von Minuten abgeschlossen werden, und die Kosten für das Grafikdesign wurden überflüssig. Nachdem der Text geprüft und freigegeben worden war, dauerte das Drucken etwa zwei Wochen. Dieses Unternehmen geht jetzt jedoch zum Drucken auf Abruf über, das durch eine Anfrage des jeweiligen Händlers ausgelöst wird.

Abbildung 2: Neuer Prozess für das Veröffentlichen von Katalogen

Die Marketing- und Vertriebsmanager, die zuerst skeptisch gewesen waren, sahen das Potenzial für zusätzliche Kataloge. Das zweite Projekt war ein Katalog für Händler außerhalb der USA mit anderen Preisen, anderen Händlernachlässen und einer eingeschränkten Produktpalette. Metadaten ermöglichten das einfache Auswählen von Produkten für stärker eingeschränkte Märkte, wodurch der einheitliche Ansatz des vorherigen Designprozesses ersetzt wurde. Der automatisierte Publishing-Prozess ermöglicht es dem Unternehmen auch, Kataloge viel häufiger als früher herzustellen.

Das Unternehmen plant jetzt, die DITA-Themen und den Publishing-Prozess mit der eCommerce-Webseite und dem automatisierten Online-Beschaffungsprozess zu verknüpfen.

Automatisiertes Publishing der nächsten Stufe

Aber das Automatisieren des Publishing-Prozesses und das Integrieren von XML-strukturierten Texten mit Daten aus einer verknüpften Datenbank ist nur der erste Schritt des Katalog-Publishing. In einem anderen Unternehmen stellten wir das Potenzial für individualisierte Kataloge fest, die auf Abruf für einen Vertriebsmitarbeiter hergestellt werden.

Wieder werden die grundlegenden Informationen über das Produkt in den DITA-Themen verfasst und gemeinsam mit den für den Katalog erforderlichen Zeichnungen und Fotos in einem Managementsystem für Inhaltskomponenten gespeichert.

Die Kataloganalyse in diesem Projekt umfasste nicht nur beschreibende Informationen, sondern auch Datentabellen und -diagramme. Die ursprüngliche Präsentation der Inhalte war ebenso chaotisch wie im ersten Projekt. Jeder Produktbereich des Printkatalogs war einzigartig, und jede einzelne Seite war individuell gestaltet. In einigen Fällen waren die Listen der Produktvorteile und wichtige technische Daten gekürzt worden, damit sie in das Seitenlayout passten.

Wieder einmal war die Standardisierung der erste Schritt. Gemeinsam mit dem Marcom-Management identifizierten wir für jedes Produkt einen Standardsatz an Inhalten und gestalteten ein einheitliches Layout, das über das DITA Open Toolkit und eine XSL-FO-Stilvorlage hergestellt werden kann.

Aber die wichtigste Frage war, wie man die Vertriebsmitarbeiter dazu bekommen würde, die Quellinformationen zu nutzen, um individuell angepasste Kataloge herzustellen. Wir wussten, dass die Vertriebsmitarbeiter lieber einzelne Kataloge für einzelne Kunden erstellen, als den riesigen Katalog der gesamten Produktpalette herumzutragen. Aber sie wollten nichts mit DITA-Themen und XML zu tun haben.

Daraufhin erstellten wir eine SharePoint-Schnittstelle, die es dem jeweiligen Vertriebsmitarbeiter ermöglicht, aus einer Reihe von Optionen zu wählen, einschließlich Produktnamen, Art der Branche und anderen Schlüsselmerkmalen der Inhalte. Indem die Vertriebsmitarbeiter einfach Kästchen anklicken, erstellen sie jeweils ihren eigenen Katalog, der vollständig formatiert ist und sofort heruntergeladen und gedruckt werden kann.

In einem ähnlichen Projekt einige Jahre zuvor ermöglichten wir es dem Vertriebsmitarbeiter, eine einfache anklickbare Oberfläche auf einer Webseite zu nutzen, um bestimmte Funktionen für eine Reihe von Produkten auszuwählen und ein Deckblatt mit dem Namen des Kundenunternehmens zu wählen. Weil die Vertriebsmitarbeiter sehr dezentral arbeiteten, gaben wir ihnen sogar die Möglichkeit, einen Druckanbieter in der Nähe auszusuchen. Sie mussten nur noch zum Druckanbieter fahren und die fertigen Kataloge für ihren nächsten Vertriebsbesuch abholen.

Möglichkeiten suchen

In den meisten Unternehmen ist das Entwickeln von Produktkatalogen und Preislisten kostenintensiv, zeitaufwendig und mühsam. Es stellt das ultimative statische Veröffentlichen dar. Aber die Argumente für das Dynamic Publishing von Kataloginhalten sind für diejenigen, die den Gewinn im Blick haben, sehr überzeugend:

• Verkürzen der Markteinführungszeit für Kataloginhalte von Monaten auf Tage
• Verringern der Kosten für das Entwickeln des endgültigen Kataloglayouts auf die ursprüngliche Entwicklung von XSL-FO-Stilvorlagen
• Ermöglichen des Entwickelns von individuell angepassten Katalogen aus Inhalten einer einzigen Quelle
• Ermöglichen des Druckens von individualisierten Katalogen auf Abruf
• Gewährleistung, dass die Preisdaten korrekt und aktuell sind, da sie direkt aus den Beschaffungsdatenbanken stammen
• Ermöglichen des Entwickelns individualisierter Kataloge durch einzelne Vertriebsmitarbeiter auf Abruf
• Verknüpfen des Kataloginhalts mit eCommerce-Webseiten

Zweifellos gibt es in Ihrem Unternehmen noch viele andere Möglichkeiten für das Dynamic Publishing. Ihr Anfangspunkt ist es, eine einzelne Quelle für das gesamte Material (Text, Bilder und Preisdaten) frei von Formatierung (XML/DITA) zu entwickeln und sie Mitarbeitern und Kunden über eine intuitive und einfach verfügbare Benutzeroberfläche zu präsentieren.

Mark Gross, Data Conversion Laboratory

Das von mir gegründete Unternehmen Data Conversion Laboratory wandelt seit dreißig Jahren Dokumente um. Ab und an fragt mich jemand, den ich lange nicht gesehen habe „Machst du das immer noch?“ oder „Gibt es dafür keine Software?“.

Wenn es so einfach wäre, dann würde natürlich alles automatisiert, wie es bei Nachrichten-Feeds, Finanztransaktionen und anderen standardisierten Datenflüssen bereits der Fall ist. Aber wenn es um Dokumente und Bücher geht, lässt sich die Kreativität nicht durch Regeln und Stilvorlagen einengen, vor allem kurz vor Ablauf der Deadline, wenn man ein bestimmtes Aussehen erreichen möchte und MS Word nicht mitspielt. Tatsächlich können Dokumente alle möglichen Inhalte enthalten, und Computersoftware kann mit „Zufälligkeit“ nicht gut umgehen.

Auch das, was für das menschliche Auge wie ein einfaches Buch aussieht ‒ ein Buch, das ausschließlich Text enthält, weder Tabellen noch Links ‒, führt immer noch zu Komplikationen, die dafür nicht konzipierte Software ausbremsen. Bei einem kürzlich durchgeführten Test mit kostenlosen Softwarepaketen hat keines perfekt abgeschnitten. Jedes einzelne hatte Probleme. Um die Dinge weiter zu komplizieren, gab es bei jedem Buch unterschiedliche Probleme (das aufgezeichnete Webinar enthält Beispiele).

Werden wir flexibel

Um die hohe Qualität und die individuell angepassten Inhalte zu liefern, die die Kunden erwarten ‒ und in manchen Fällen fordern ‒, müssen wir ernsthaft darüber nachdenken, automatisierte Ströme standardisierter Inhalte zu erstellen ‒ etwas, was die meisten Unternehmen heutzutage nicht haben.

Damit Unternehmen mit großen Inhaltssammlungen ihre Inhalte verteilen und monetarisieren können, scheint es die beste Lösung zu sein, ein flexibles standardisiertes Inhaltsmodell zu übernehmen und die Inhalte in einem entsprechenden Content-Management-System zu speichern. In unserer mobilen verbundenen Welt, in der wir immer online sind, bedeutet das, den Kunden die Inhalte auf dem Gerät ihrer Wahl anzubieten. Es bedeutet auch das Sichern dieser Inhalte für die Zukunft, so dass sie schnell und effizient für die vielen Geräte vorbereitet und ausgegeben werden können, die erst noch auf den Markt gebracht werden.

Es gibt viele Standards für Inhalte, aus denen man wählen kann: HTML, EPUB, XML, PDF und DITA. Aber welcher ist für Ihren Zweck am besten geeignet? Und für Ihre Zielgruppe? Und für die Zielgruppe der Zukunft? Müssen Sie mehrere Standards unterstützen?

Nehmen wir erst einmal an, dass ein stabiles XML-Format das Richtige ist, um Ihren Inhalt zu speichern ‒ das für Ihre Inhalte am besten geeignete spezifische Format wird erst noch diskutiert werden müssen. Es scheint jedoch, dass für die meisten großen Sammlungen der Wechsel zu einem der einfacheren Formate wie HTML oder ePUB aufgrund der mangelnden Flexibilität dieser Formate riskant sein kann.

ePUB beispielsweise, jetzt in Version 3.0, ist auf die Anforderungen elektronischer Bücher, wie sie zurzeit existieren, spezialisiert. Es ist sehr gut möglich, dass die Funktionen Ihrer Inhalte nicht alle einfach im ePUB-Standard definierbar sind und auf aktuellen Geräten nicht angezeigt werden können. Wenn Sie sich darauf beschränken, auf die aktuelle Version von ePUB zu konvertieren, begrenzen Sie möglicherweise Ihre Inhalte, wenn neue Funktionen, die man sich jetzt noch nicht vorstellen kann, eingeführt werden. Das Gleiche gilt für HTML, das zum Darstellen von Inhalten gestaltet wurde.

Um Ihre Investition in das Umwandeln in ein Standardformat zu schützen, ist es sicherer, die Inhalte in eine stabilere Version von XML, z. B. DITA, DocBook, NLM, TEI, S1000D und viele andere für spezielle Zwecke entwickelte XML-Standards, umzuwandeln und zu speichern. Wenn sie richtig gestaltet sind, können Sie Ihre Inhalte dann in Zukunft automatisch in ePUB, HTML, PDF und in andere endgültige Formate umwandeln.

Gut, und warum ist das Umwandeln so schwierig?

Wenn alle Autoren ihre Dokumente mit der Absicht schreiben würden, sie standardisieren und umwandeln zu lassen, wäre das Leben einfach (und wir hätten nicht so viel zu tun). Aber tatsächlich sind die meisten Inhalte nicht einfach extrahierbar, und die Details, die für eine vollständige Umwandlung erforderlich sind, fehlen. Vieles muss korrigiert werden und vieles muss aus dem Inhalt abgeleitet werden.

Sehen wir uns beispielsweise die Schwierigkeiten beim Extrahieren von Inhalten aus PDF-Dateien an. Da PDF ein Druckformat ist, sind PDF-Dokumente im Allgemeinen weniger strukturierte Versionen ihrer Originale aus der Textverarbeitung. Während PDF-Inhalte so gestaltet werden, dass sie gut aussehen, enthalten sie sehr wenig Struktur ‒ d. h. es gibt wenig Hinweise zur Funktion von Textelementen (z. B. Abschnitte, Leerzeichen, Zeilenwechsel) und dazu, wie sie in einem anderen Kontext (z. B. in einem eBook) dargestellt werden sollen. Während das Umwandeln gründlich strukturierter Inhalte nach XML sehr einfach ist, enthält PDF zu wenig ausdrückliche Strukturierung. Aber ein sogar noch grundlegenderes Problem hat damit zu tun, den Inhalt korrekt aus der PDF-Datei zu extrahieren.

Zu den Beispielen für Probleme, denen Sie bei kommerziellen Paketen wahrscheinlich begegnen, gehören die folgenden:

Falsche Leerzeichen zwischen den Worten

Obwohl die Leerzeichen normalerweise korrekt extrahiert werden, da PDF-Dokumente die Abstände visuell erstellen (d. h. sie werden nicht als „ein Standardleerzeichen“ oder „zwei Standardleerzeichen bezeichnet), werden die Abstände zwischen den Worten von der Umwandlungssoftware manchmal falsch interpretiert, was dazu führt, dass während der Umwandlung von PDF nach Word manchmal Leerzeichen fälschlicherweise hinzugefügt oder gelöscht werden. Deshalb fließen in eBooks, die nicht vollständig korrigiert wurden, die Worte zusammen oder es treten andere Fehler bei den Leerzeichen auf.

Abgrenzung von Absätzen

In den meisten Fällen enthalten PDF-Dokumente keine ausdrücklichen Informationen, die angeben, wo Absätze beginnen oder enden. Die Umwandlungssoftware muss also, basierend auf der „visuellen“ Interpretation der Darstellung der Textstücke, auch das erraten. Auch wenn die Umwandlungssoftware häufig richtig rät, kann die Abgrenzung von Absätzen eine Quelle für Extrahierungsfehler sein, insbesondere wenn die Absätze sehr kurz sind oder Seiten übergreifen oder wenn Bilder oder Tabellen hinzukommen.

Bindestriche

Bindestriche stellen ein Problem dar, denn sie dienen unterschiedlichen Zwecken, die automatisierte Systeme nicht unterscheiden können. Während der Bindestrich, der einen Begriff wie „Bindestrich-Frage“ verbindet, unabhängig davon erscheinen sollte, an welcher Stelle des Dokuments sich die Worte befinden, wird ein Bindestrich, der aufgrund eines Zeilenwechsels erscheint (z. B. ge-trennt), zu einem hässlichen Fehler, wenn sich das Wort in der Mitte der Zeile befindet. Auch das werden Sie in eBooks, die Sie herunterladen, häufig sehen.

Hervorhebungen

Je nachdem, wie ein Dokument in PDF ausgegeben wird, kann das richtige Extrahieren der Hervorhebungen aus einem PDF-Dokument manchmal zu einem Problem für die Umwandlungssoftware werden. Das liegt wiederum daran, dass die PDF-Struktur nur eine visuelle Darstellung ist; während der Text hervorgehoben scheint, wird er von der PDF-Datei nicht als „hervorgehoben“ gekennzeichnet ‒ die Umwandlungssoftware muss anhand dessen, was sie aus der Darstellung des Texts liest, so gut wie möglich raten.

Hoch- und Tiefstellungen

Da sich in PDF-Dokumenten die Behandlung von hoch- und tiefgestellten Zeichen darauf beschränkt, wie sie beim Layout der PDF-Datei erscheinen (statt sich auf eine Art Tag für „Hochstellung“ und „Tiefstellung“ zu beziehen), entstehen bei Extrahierungssoftware im Allgemeinen Probleme damit, die vertikale Ausrichtung des Texts festzustellen. Daher werden Hoch- und Tiefstellungen von Extrahierungssoftware häufig falsch interpretiert.

Sonderzeichen

In PDF-Dokumenten werden Sonderzeichen, wie Buchstaben aus Fremdsprachen oder mathematische Symbole, oft durch ungewöhnliche oder eigene Zeichen dargestellt. Um diese Zeichen für eine Textverarbeitungssoftware zu extrahieren, müssen sie zunächst in eine standardmäßigere Darstellung (z. B. ISO oder Unicode) umgewandelt werden. Obwohl viele Umwandlungssoftware-Suites Umwandlungstabellen enthalten, um mit solchen Zeichen umgehen zu können, ist es unmöglich, mit der großen Anzahl ungewöhnlicher und eigener Zeichen Schritt zu halten, die verwendet werden, und deshalb werden viele Sonderzeichen nicht korrekt extrahiert.
 

Subfonts

Die Methode der PDF-Dateien beim Einbetten von Schriftarten ist ein weiteres Hindernis für die korrekte Extraktion. Wenn PDF-Dateien erstellt werden, speichert das PDF-Dokument manchmal nicht die Informationen für die gesamte Schriftart, sondern nur die Teile der Schriftart, die in einem bestimmten

Dokument verwendet werden. Der Zugriff auf die Zeichen dieser „Unterschriftart“ erfolgt über eine indirekte Tabelle innerhalb des PDF-Dokuments, wodurch die korrekte Interpretation und Extraktion der Zeichen der Unterschriftart schwierig wird. Viele Konvertierungstools können diese Zeichen überhaupt nicht umwandeln und produzieren statt korrekt extrahiertem Inhalt „Abfalltext“.

Tabellen

Tabellen gehören zu den am schwierigsten zu extrahierenden Elementen von Dokumenten. Das liegt daran, dass das Erscheinungsbild auch einfacher Tabellen von zahlreichen Merkmalen bestimmt wird. Dazu gehören unter anderem die Abgrenzung von Zeilen und Spalten, Überschriften und Text, vertikale und

horizontale Zellenbreite, Zellenseparatoren und vertikale und horizontale Zellenausrichtung. Da keine dieser Informationen in der ursprünglichen PDF-Datei enthalten ist, ist es für automatisierte Werkzeuge beinahe unmöglich, Tabellen genau so zu reproduzieren, wie sie im Originaldokument dargestellt wurden.

Während manche kurze oder einfache Dokumente eine Umwandlung von PDF zu Word (und daher auch von PDF zu ePUB) mit minimalen Schwierigkeiten überstehen können, wird man bei langen oder komplexen Dokumenten immer einer Vielzahl dieser Hindernisse begegnen. Die der Extraktion von PDF-Texten inhärenten Hindernisse sollten zunächst, wenn möglich, die Notwendigkeit betonen, die Originalversionen von Quelldokumenten im Format der Textverarbeitung zu erhalten, und zweitens darauf hinweisen, wie wichtig bei jedem Umwandlungsprozess ein guter Qualitätssicherungsprozess ist.
 

Was soll ich also jetzt tun?

Offensichtlich werden viele Millionen Seiten konvertiert, wir selbst konvertieren Millionen von Seiten. Es gibt Lösungen für alle oben genannten Probleme und Methoden, um mit allen oben genannten Problemen umzugehen, und noch mehr, was in den zukünftigen Kolumnen diskutiert werden wird.

Fragen zur Umwandlung?

Wenn Sie spezifische Fragen zur Umwandlung haben, die Sie mir stellen möchten, nutzen Sie die Kommentarfunktion dieser Webseite, um sie zu stellen. Ich werde mein Bestes tun, um eine Antwort für Sie zu finden.

Scott Abel, Editor, TheDynamicPublisher.com

Es scheint, dass der Schwerpunkt dieser Online-Publikation eindeutig zugeordnet ist: Definieren des Begriffs „Dynamic Publishing“. Aber ich entdeckte bei meinem Versuch, ein gemeinsames Vokabular zu erstellen, schnell, dass meine Aufgabe viel komplizierter ist, als ich zunächst dachte.

Wie sich herausstellte, gibt es feine Unterschiede zwischen den Definitionen, die Branchenführer und erfahrene Berater nutzen, um zu erklären, was sie meinen, wenn sie über Dynamic Publishing sprechen. Tatsächlich bieten einige der am häufigsten zitierten Fachleute keine genau abgegrenzte Definition des Begriffs, sondern wählen stattdessen verwandte Bezeichnungen wie „Dynamische Inhalte“ oder „Inhaltsausgabe“.

Laut Ann Rockley, Autorin von „Managing Enterprise Content: A Unified Content Strategy“ (Verwalten von Unternehmensinhalten: eine vereinheitlichte Inhaltsstrategie) (Zweite Auflage) [New Riders, 2012] unterscheidet sich dynamischer Inhalt von seinem statischen Verwandten dadurch, dass „dynamischer Inhalt nicht in einem oder als Dokument existiert; es ist Information, die nur bei Bedarf zusammengestellt wird. Er existiert als eine Reihe von Informationsobjekten, die als Reaktion auf eine Anforderung des Anwenders oder [andere] Anforderungen zusammengestellt werden.“

„Dynamischer Inhalt“, so Rockley, „ist Inhalt, der automatisch zusammengestellt wird, um die spezifischen Anforderungen der Anwender zu erfüllen, er bietet ihnen genau das Gewünschte zum vorgegebenen Zeitpunkt und im gewünschten Format.“

Rockleys Erklärung dynamischer Inhalte ist einfach, aber reicht sie aus, um die Frage zu beantworten, was Dynamic Publishing ist?

JoAnn Hackos erläutert in ihrer 2002 erschienenen Arbeit, „Content Management Strategies for Dynamic Web Delivery“ (Content-Management-Strategien für die dynamische Web-Ausgabe) (Wiley) einige Vorteile der „dynamischen Präsentation von Inhalten“, einschließlich dem „großen Potenzial, webbasierte inhaltsreiche Ressourcen für den Anwender wertvoller zu gestalten.“
„Die Anwender scheinen ein großes Verlangen danach zu haben, mit Ressourcen zu arbeiten, die ‚individuell’ an ihre Bedürfnisse angepasst sind und effektiv auf ihre Anfragen reagieren“, schreibt Hackos. Sie scheinen es auch „vorzuziehen, Informationsquellen, die sie häufig nutzen, zu personalisieren“.

Hackos erklärt einige der Vorteile, die entstehen, wenn man Inhalte dynamisch bereitstellt, vor allem im Web, während sie auch einen weiteren Begriff einführt, der definiert werden muss: Personalisierung.

Quark Software, die Sponsoren, die TheDynamicPublisher.com gegründet haben, sagen, dass ihrer Meinung nach das Dynamic Publishing „auf zwei grundlegenden Prinzipien basiert: Verwendung von wiederverwendbaren strukturierten XML-Inhalten und Automatisierung der Bereitstellung dieser Inhalte für alle Medienformate.“

Quark betont die Automatisierung aller Prozesse, die in einer vollständigen Dynamic-Publishing-Lösung enthalten sind, einschließlich der Automatisierung von:

• Wiederverwendung von Inhalten
• Layout
• Workflow
• Formatierung und Multichannel-Publishing
• Kundenspezifischer und personalisierter Inhalt

Und obwohl alle diese Informationen interessant sind und zum Denken anregen, habe ich immer noch keine klare und eindeutige Definition für das Dynamic Publishing. Sollte es nicht mittlerweile eine Wikipedia-Seite zu diesem Thema geben? Wie sich herausstellt, gibt es eine. Aber leider ist sie diesmal nicht sehr hilfreich, obwohl die beliebte von den Anwendern erstellte Enzyklopädie oft nützlich ist, wenn es darum geht, semantische Herausforderungen zu bewältigen.

Was kann ich als Redakteur also tun?
Nachdem ich mich einige Tage mit dieser Herausforderung abgemüht hatte, stellte ich fest, dass ich vielleicht am besten eine zuverlässige Definition bekomme, wenn ich die Community um Hilfe bitte. Und hier kommen Sie ins Spiel.
Wie lautet Ihre Definition des Dynamic Publishing? Bitte nutzen Sie die Kommentarfunktion dieses Blogs, um mir Ihre Meinung zu diesem Thema mitzuteilen. Nächste Woche fasse ich Ihre Erkenntnisse zusammen und versuche, eine Definition zu finden, die einen großen Teil Ihrer Gedanken umfasst.

Scott Abel, Editor, TheDynamicPublisher.com

Es ist schwierig, zum richtigen Zeitpunkt die richtigen Inhalte für die richtigen Personen im richtigen Format und der richtigen Sprache auszugeben, und es wird durch Menagerie der mobilen Geräte, die schneller aus dem Boden zu schießen scheinen als Gänseblümchen nach dem Regen, noch schwieriger ‒ insbesondere, wenn man sich auf herkömmliche Publishing-Techniken verlässt. Wenn Ihr Unternehmen den meisten anderen ähnelt, wird Ihr Vertrauen in printzentrierte Prozesse und veraltete arbeitsintensive Workflows Sie im Stich lassen, wie sehr Sie es auch versuchen, und wie viel Geld Sie auch in das Problem investieren. Aber Sie sind nicht allein. Es gibt Menschen, die Ihr Problem verstehen und die bereit sind, das, was sie gelernt haben, mit Ihnen zu teilen, um Ihnen zu helfen, außerhalb der herkömmlichen Publishing-Denkmuster zu denken.

Hier kommt TheDynamicPublisher.com. Ursprünglich war TheDynamicPublisher.com eine Webseite für Inhalte über das Dynamic Publishing, wie es von Quark Software erdacht wurde. Heute ist die Webseite als anbieterunabhängiger umfassender Anlaufpunkt für Informationen zum Dynamic Publishing und damit verknüpften Themen neu aufgelegt worden. Ich bin Ihr Gastgeber, Scott Abel, The Content Wrangler. Meine Aufgabe ist es, den besten und klügsten Fachleuten weltweit relevante, informative und nützliche Inhalte über das Dynamic Publishing „zu entreißen“ und sie ihnen zu präsentieren.

Das Dynamic Publishing ermöglicht es, Inhalte effizient und auf Abruf auf mobilen Geräten auszugeben.

Und das ist noch nicht alles. Ich bin auch dafür verantwortlich, diese Webseite zu einer lebhaften Community für Inhaltsprofis zu machen, die daran interessiert sind, die Methoden, die Standards und die Softwaretools, die benötigt werden, um relevante Inhalte für die, die sie benötigen, dynamisch und auf Abruf zu erstellen, zusammenzustellen und auszugeben, zu fördern.

Um mein Ziel zu erreichen, suche ich Unterstützung aus der Menge, damit ich einen kollektiven Wissensfundus und eine Community aufbauen kann, die Ressourcen für jene darstellen, die sich von den ineffizienten und alten Möglichkeiten zum Erstellen, Verwalten und Ausgaben von Inhalten fortbewegen wollen. Machen Sie mit?

Wie können Sie sich beteiligen?

Wenn Sie Fragen zu dynamischen Inhalten und damit verknüpften Themen haben, schicken Sie sie mir per E-Mail und ich werde einen oder zwei Fachleute finden, die sie Ihnen beantworten.

Wenn Sie ein Fachexperte sind und einen Artikel schreiben möchten, teilen Sie mir mit, worüber Sie schreiben wollen und in welcher Verbindung es zum Dynamic Publishing steht.

Wenn Sie für ein Unternehmen arbeiten, das Softwareprodukte oder damit verbundene Dienstleistungen anbietet, um Unternehmen zu helfen, dynamische Inhalte zu erstellen, und wenn Sie ein Sponsor werden möchten, schicken Sie mir eine E-Mail und ich werden Ihnen mitteilen, wie Sie sich beteiligen können.

Und wenn Sie an den auf diesen digitalen Seiten präsentierten Themen interessiert sind, lesen Sie, kommentieren Sie, fragen Sie. Werden Sie ein Teil der Community!

TheDynamicPublisher.com ist immer in Bewegung. Wir aktualisieren und verbessern die Webseite nach und nach. Wenn Sie Ideen oder Vorschläge dazu haben, wie man die Webseite verbessern kann, teilen Sie sie mir bitte mit.

Das Thema, das derzeit in der Publishing-Welt in aller Munde ist, ist „Digital Publishing“. Dieser Begriff wird meist dazu benutzt, um das Veröffentlichen auf „neuen Geräten“, wie dem iPad, Android-Tablets und anderen mobilen Geräten zu beschreiben. Erstaunlich ist, dass obwohl die meisten Designer und Firmen planen, Inhalte auf Tablets zu veröffentlichen, sich viele Kreative nicht sicher sind, wie man auf diesen Geräten veröffentlicht bzw. Apps erstellt.

Ein Hype angesichts einer neuen Technologie und ein lebhafter neuer Markt sind ja oft beste Voraussetzungen, um Innovationen voranzutreiben. Erinnern Sie sich an das Internet in den 90er-Jahren? Man kann viele Parallelen zwischen dem Höhepunkt des Internet-Hypes und der heutigen rasanten Verbreitung des Digital Publishing ziehen. Wir können mit großer Wahrscheinlichkeit davon ausgehen, dass Tablets langfristig auf dem Markt bestehen werden (so wie es das Web – wenn auch in weiterentwickelter Form – immer noch gibt). Und Apple hat seit der Einführung des iPad vor etwas über einem Jahr diesen Markt wenn nicht sogar gegründet, dann doch sichtbar beschleunigt.

Es ist interessant zu beobachten, wie aufkommende Trends und neue Märkte sich entwickeln: Zuerst stürzen sich alle auf die ersten verfügbaren Lösungen und nutzen diese ohne Anpassungen. Dann werden diese Lösungen basierend auf Vorlieben der Kunden, Austesten von Geschäftsmodellen und anderen Rückmeldungen aus den Märkten Schritt für Schritt verbessert.

Beim Digital Publishing konnte man sehen, dass Publisher jeglicher Art (also sowohl Industriekunden und Kataloghersteller wie auch Zeitungs- und Zeitschriftenverlage und jegliche andere „Inhaltslieferanten“ wie z. B. Fotografen, Künstler und Designer) schnell „fürs Tablet“ veröffentlichten.

All diese Anwendergruppen scheinen sich einig zu sein, dass der beste Weg, Inhalte auf Tablets zu bringen, die „App“ ist ‒ also Inhalte in einer eigenständigen Anwendung zu veröffentlichen, die die „Leser“ herunterladen und installieren können.

Die meisten Designer und Verlage unternahmen Ihre ersten Tablet-Gehversuche mit Apps, die ich als erste Generation bezeichnen würde. Diese Apps erinnern an interaktive PDF-Dateien und ähneln in vielen Aspekten Printmedien: Ein Titelbild, dann Inhaltsverzeichnisseiten, eine lineare Seitenstruktur oder vielleicht schon Seitenstapel (auch Wäscheleinenformat genannt). Kurz gesagt: Das gesamte Leseerlebnis basiert auf dem Umblättern bzw. Wischen von Seiten. Und obwohl die Seiten solcher Apps Multimedia-Objekte (wie Audio, Video, Animationen etc.) beinhalten und es sich um echte Apps handelt, fühlen sie sich somit doch wie „aufgemotzte“ PDF-Datei an.

Diese Methode funktionierte eine Zeitlang gut und begeisterte Leser, die fasziniert vom neuen Medium waren und daher oft auch bereit waren, für die Inhalte zu zahlen. Bald konnte man jedoch feststellen, dass das Interesse nachließ, da die Apps nicht genügend Mehrwert oder Vorteile gegenüber traditionellen Formaten boten (außer vielleicht den Vorteil, auch unterwegs zur Verfügung zu stehen).

Ich bin der festen Überzeugung, dass die anfängliche Begeisterung der Leute auch deshalb wieder deutlich abflaute, weil Inhalt und Design nicht auf das Gerät zugeschnitten waren und die Leseerfahrung sich nicht iPad-typisch anfühlte, sondern wie ein Printmedium. Das bedeutet natürlich nicht, dass PDF-Dateien oder Printmedien schlecht sind, nur erwarten die Leser auf dem Tablet etwas anderes. Sie lesen ja auch keine ausgedruckten Webseiten.

Oder erinnern Sie sich an die auf Flash basierenden Blätterkataloge oder -zeitschriften? Eine Zeitlang schienen Sie „in“ zu sein, ein Muss für jeden Publisher. Und sie zeigten auch gut, was Technologie leisten kann. Dazu sahen sie cool aus, so dass viele Kunden dazu brachte, diese auszuprobieren. Oft blieb es aber beim einmaligen Ausprobieren oder Neugierde stillen. Die meisten Leser kehrten dann wieder zum PDF, der HTML-Variante oder zur Printversion zurück. Der Grund ist klar: Blätterkataloge, die Papier und Bindung auf einem Bildschirm simulieren, die es dort gar nicht gibt, fühlten sich einfach nicht natürlich an und gaben Lesern keine Vorteile (eher sogar Nachteile, und wenn es nur die hohen Hardwareanforderungen von Flash waren, die das Leseerlebnis langsam machten).

Derzeit sieht man viele Apps, die ich der zweiten Generation zuordnen würde.: Sie fühlen sich eher an wie Webseiten als wie PDF-Dateien. Das ist eine Verbesserung, denn digitale Geräte wie Tablets sind ja eher mit Webseiten verwandt als mit Papier.

Aber warum dann nicht gleich eine HTML-Seite in einem Webbrowser auf einem Tablet verwenden? Es scheint, dass viele Leser, die mobile Geräte verwenden, Browser als „altmodisch“ und als eine Technologie aus dem letzten Jahrzehnt ansehen. Eine kürzlich verfasste Studie (http://goo.gl/cgKxb) zeigt, dass heute Anwender auf Tablets mehr Zeit in Apps als im Browser verbringen. Das bedeutet im Umkehrschluss wahrscheinlich, dass Ihre Inhalte mehr Aufmerksamkeit bekommen und mehr Leser (Kunden, Verbraucher) anziehen, wenn sie in einer App erhältlich sind.

Verstehen Sie mich nicht falsch, natürlich sehe ich viele Anwendungsfälle, für die Apps der ersten und der zweiten Generation gut funktionieren und auch ihre Berechtigung haben. Wofür ich Ihren Blick schärfen möchte ist: Wie gewinne ich am besten Leser (also Kunden), welche Darbietungsform ist dafür am attraktivsten? Der Inhalt ist natürlich die eine Seite, Design und Leseerlebnis oder Leseerfahrung die andere. Also, heben Sie sich vom Gewohnten, dem Alltäglichen ab: Gestalten Sie Apps der nächsten Generation.

Gestalten Sie digital und auf das Medium zugeschnitten.

Und dafür sollten Sie sich als erstes von der Metapher „Seiten umblättern“ lösen. Gestalten Sie Ihre Seiten „Fingergesten-freundlich“, und lassen Sie das Layout sich automatisch dem derzeit angezeigten Inhalt anpassen. Das ist eine neue Art, Inhalte zu präsentieren: Ihre Leser bleiben lange auf demselben Layout, und Ihre Inhalte fühlen sich dennoch nicht statisch an. Schließlich, und natürlich nur, wenn es für Ihr Thema sinnvoll ist: Nutzen Sie 360°-Abbildungen, 3D-Welten und Panoramaerlebnisse; zeigen Sie gestaltete Inhalte in Diashows, die z.B. durch Antippen erweitert werden, um einen größeren Ausschnitt anzuzeigen, und vieles mehr. Oder ‒ kurz gesagt ‒ machen Sie das Beste aus den technischen Möglichkeiten, die die heutigen Tablets bieten.

Der Digital Publishing Markt entsteht gerade, und das ist die große Chance, wenn Sie jetzt mit dabei sind und mitgestalten. Es gibt noch keine fest definierten Anforderungen, keine festgefahrenen Erwartungen, es gibt viel Raum, um neue Erlebnisse eigens für Tablets zu schaffen, die es ermöglichen, Inhalte einfacher aufzunehmen und vor allem zu erleben. Vor diesem Hintergrund wird es auch interessant sein zu sehen, wie der Markt Web Apps annimmt. Aber das ist ein anderes Thema.

Wenn Sie auf das Bild klicken, können Sie ein Beispiel einer Seite sehen, die sich an den Inhalt anpasst, wenn dieser nach oben und unten gewischt (gescrollt) wird. 

Die interaktive Seite für das iPad wurde erstellt in QuarkXPress 9 mit App Studio.
Autor: Matthias Günther

Kürzlich wurde ich gefragt: „Welche Arten von Dokumenten sind für das Dynamic Publishing geeignet? Und welche Arten sind eher ungeeignet?“

Um die erste Frage zu beantworten: Für das Dynamic Publishing geeignete Dokumente sind im Allgemeinen

•    Im Rahmen eines förmlichen Prozesses erstellt. Es gibt im Unternehmen Personen, die speziell für das Erstellen, Prüfen, Genehmigen und die Verteilung von Informationen zuständig sind. Marketingmaterial und Produktdokumentation sind gute Beispiele.
•    Häufig erstellt. Sie müssen häufig oder regelmäßig veröffentlicht werden. Beispielsweise Newsletter für Mitarbeiter oder Partner, Verkaufs- oder Projektangebote und beinahe jede Zeitung und Zeitschrift sowie alle Nachrichteninhalte, die täglich, wöchentlich oder monatlich veröffentlicht werden.
•    Personalisiert. Z. B. Finanzberichte, Direktwerbung oder sonstige Kundenkommunikation, bei der der Inhalt die spezifischen Bedürfnisse des Empfängers erfüllen muss.
•    Häufig aktualisiert. Z.B. Datenblätter, Spezifikationen und andere Informationen, die aktualisiert werden, um die Markteinführung neuer Produkte, Produktfunktionen, Dienstleistungen oder anderer neuer Angebote zu unterstützen.
•    Kostspielig zu übersetzen, zu aktualisieren und neu zu veröffentlichen. Das kann bei Unternehmen, die in mehreren geografischen Regionen tätig sind, für jede der oben genannten Dokumentarten gelten.
•    Müssen über mehrere Kanäle veröffentlicht werden, einschließlich Print, Web und digitaler Geräte. Diese Dokumentenarten besitzen einen beträchtlichen Wert für den Erfolg Ihres Unternehmens, denn die Informationen sind grundlegend, um Marketing, Vertrieb, Installation, Betrieb, Wartung, Reparaturen, Einhaltung von Vorschriften und Gesetzen und andere wichtige Geschäftsfunktionen zu unterstützen.

Umgekehrt gibt es wahrscheinlich keine Rechtfertigung, um Dynamic Publishing anzuwenden für

•    Dokumente, die NICHT im Rahmen eines förmlichen Prozesses erstellt werden (z. B. E-Mails)
•    Dokumente, die selten oder nur einmal erstellt werden (z. B. Jahresberichte)

Die folgende Grafik zeigt, welche Merkmale einer Dokumentenart dafür sprechen, diese Dokumentenart mit einem Dynamic-Publishing-System herzustellen und zu veröffentlichen. Es müssen nicht alle Merkmale Ihres Dokuments am rechten Rand des Spektrums liegen, nutzen Sie sie nur als Indikatoren. Ihre Entscheidung beruht hauptsächlich auf den Kosteneinsparungen, der Zeitersparnis und den positiven Effekten, die durch eine verbesserte Genauigkeit, einen bequemeren Zugang und einer höheren Relevanz Ihrer Informationen erreicht werden.

Wenn Sie überlegen, ob die von Ihnen veröffentlichten Dokumente für das Dynamic Publishing geeignet sind, werden Sie feststellen, dass Sie sich nicht mehr auf die Publikationen als Ganzes konzentrieren, sondern dass sich Ihr Denken hin zum Erstellen von Informationskomponenten verschiebt, die Ihr Dynamic-Publishing-System automatisch zu unterschiedlichen Arten von Publikationen zusammensetzen und automatisch über unterschiedliche Medienarten veröffentlichen kann. Denn genau das meint Dynamic Publishing: das automatisierte, personalisierte Veröffentlichen aus einer einzigen Inhaltsquelle in alle Medienkanäle.

Mitte der 1980er Jahre haben alle, die mit der Verbreitung von Informationen zu tun hatten, das Desktop-Publishing enthusiastisch aufgenommen. Desktop-Publishing-Software und Laserdrucker gaben uns die Möglichkeit, Dokumente lesefreundlicher und die Anordnung von Elementen übersichtlicher zu gestalten. Wir konnten die Kosten für das Schriftsetzen einsparen und dennoch einen Teil der durch den Schriftsatz bereitgestellten Präsentationsqualität erreichen.

Obwohl die Standard General Markup Language (SGML) schon früh zur Verfügung stand und von großen Unternehmen wie IBM, Hewlett-Packard und vielen Behörden umfassend genutzt wurde, wurde der Bereich bald durch die Kombination aus Microsoft Word und unterschiedlichen Desktop-Publishing-Systemen dominiert. Alle diese Produkte waren proprietär ‒ d.h. von einem auf Profit ausgerichteten Unternehmen entwickelt und kontrolliert und in seinem Besitz. Wenn man Inhalte in einem Produkt erstellte, war man eigentlich an dieses Produkt gefesselt. Von einem Produkt zu einem anderen zu wechseln war sehr schwierig und kostenaufwendig und ist es auch heute noch.

Ab Mitte der 80er Jahre, in den 90ern und bis in das neue Jahrtausend hinein entschlossen sich, nachdem die eXtensible Markup Language (XML) für die Nutzung des Internets als Kommunikationswerkzeug eingeführt wurde, insbesondere große Unternehmen dazu, eigene Anwendungen zu entwickeln. Dies taten sie, indem sie mit SGML arbeiteten, den OASIS DocBook XML-Standard anpassten oder intern eine einzigartige proprietäre Umgebung für das Verfassen und Veröffentlichen von Inhalten entwickelten.

Über die Jahre arbeitete unser Comtech-Team für viele Kunden, die interne proprietäre SGML- und XML-Systeme aufgebaut hatten, darunter IBM, Hewlett-Packard, Bell Laboratories und unterschiedliche Telekommunikationsunternehmen wie Lucent, Alcatel, Nortel, und viele andere. Ich persönlich habe eng mit der Abteilung für Inhaltserstellung bei SAP zusammengearbeitet, um zu helfen, die interne Authoring-Umgebung zu entwickeln.
Der Erfolg dieser firmeneigenen SGML- und XML-Systeme beruhte auf ihrer detaillierten Anpassung, die bewirkte, dass sie genau die Inhaltsarten unterstützten, die an interne und externe Kunden ausgegeben wurden. In einigen Fällen bieten die firmeneigenen Systeme leistungsstarke Funktionalität unterstützt von benutzerfreundlichen Authoring-Umgebungen. In anderen Fällen bleibt die Funktionalität hinter der in kommerziellen Produkten angebotenen zurück, und die Benutzeroberflächen sind mittlerweile veraltet. Das Problem sind die Ressourcen. Die Kosten für das Pflegen eines firmeneigenen Systems, das ausschließlich vom Unternehmen getragen wird, sind hoch.

Einer der Telekommunikationsriesen der 1990er Jahre benötigte zur Wartung des firmeneigenen Systems 15 Mitarbeiter. Dieses Team leistete hervorragende Arbeit. Es baute Anfang der 1990er Jahre ein System nach dem neuesten Stand der Technik auf, das weiterhin finanziert wurde, so dass es aktualisiert und gepflegt werden konnte ‒ d. h. bis zum Zusammenbruch der Telekommunikationsbranche um das Jahr 2000 herum. Als Ergebnis dieses Zusammenbruchs bewertete die Geschäftsführung die Vorteile gegen die Kosten des firmeneigenen Systems neu und wechselte schließlich zu kommerziellen Produkten, die internationale Standards unterstützen. Die Kosten kommerziell entwickelter Produkte können sich durch die Implementierung bei einer großen Anzahl von Kunden amortisieren. Darüber hinaus werden die Standards, auf denen diese Produkte basieren, von einer Gemeinschaft von Freiwilligen entwickelt und gepflegt, die Branchen- und Technologieerfahrung mitbringen.

Die Motivation der Unternehmen zur Veränderung

Auf der DITA Europe Konferenz 2010 erklärten Thilo Buchholtz und Teresa Pask von SAP eloquent, warum ihre Schulungs- und Trainingsabteilung beschlossen hat, das firmeneigene XML-basierte Content-Management- und Authoring-System aufzugeben und statt dessen den OASIS DITA-Standard zu übernehmen. Sie erklärten, dass Informationen schnell verfasst und den Kunden rechtzeitig geliefert werden müssen, das sei für jeden, der mit Inhaltserstellung befasst ist, maßgeblich. Darüber hinaus müssen Inhalte aus mehreren Quellen, einschließlich von Partnern verfasste, integriert werden können. Buchholtz und Pask sagten uns, dass „es weitaus einfacher ist, neue Technologien und Modalitäten schnell zu übernehmen und Inhaltsbeiträge interner und externer Mitarbeiter sowie von Partnern beigesteuerte Inhalte zu integrieren, wenn man branchenübliche Standard-Datenmodelle und Toolsets nach Branchenstandard verwendet“.

Nach Auffassung der Abteilung „Lernen und Schulung“ von SAP

•    Unterstützt DITA die strategische Ausrichtung, in die das Unternehmen in Bezug auf Inhalte, die für Kunden wichtig sind, gehen möchte
•    Bietet DITA eine modulare Architektur, die die Mehrfachverwendung von Inhalten aus einer einzelnen Quelle unterstützt
•    Ist mehr Technologie erhältlich, die den DITA-Standard unterstützt
•    Unterstützt die Open-Source-Gemeinschaft die kontinuierlichen technologischen Veränderungen

Ich erfahre in Diskussionen mit der Geschäftsführung unterschiedlicher Unternehmen regelmäßig, dass man beschlossen hat, wie SAP von der guten, aber teuren firmeneigenen XML-Umgebung zum DITA-Standard zu wechseln. Der Wechsel verändert weit mehr als nur die Kosten für die Pflege eines In-House-Systems. Der DITA-Standard verspricht Kompatibilität, und das ist in Zeiten zunehmender Geschäftskonsolidierungen eine wichtige Überlegung.

Fusionen und Übernahmen

Was geschieht, wenn ein Unternehmen mit einem proprietären internen System ein anderes Unternehmen übernimmt, das ebenfalls ein proprietäres internes System besitzt? Im Allgemeinen muss eine Gruppe zum proprietären System der anderen Gruppe wechseln, und für gewöhnlich ist das mit hohen Kosten verbunden. Was geschieht, wenn ein Unternehmen, das den DITA-Standard verwendet, ein anderes Unternehmen übernimmt oder mit einem Unternehmen fusioniert, das denselben DITA-Standard nutzt? Die Unternehmen führen ihre Inhalte einfach zusammen, sogar wenn beide Unternehmen DITA-Spezialisierungen eingerichtet haben. Wenn sie DITA „out-of-the-box“, also unverändert nutzen, ist für die Zusammenführung nur die Integration der beiden Inhaltsmodelle erforderlich. Diese Integration ist, obwohl die Details der Architektur abgestimmt werden müssen, sehr viel einfacher und kostengünstiger als das Integrieren zweier proprietärer Systeme.

Integration von Authoring- und Content-Management-Systemen

Wenn beide Unternehmen unterschiedliche Authoring-Werkzeuge oder Content-Management-Systeme verwenden, kann die Integration sehr einfach sein, solange beide Systeme auf dem DITA-Standard basieren. Tatsächlich haben wir eine solche Migration zu einem neuen Content-Management-System unterstützt. Wir exportierten alle Daten, einschließlich aller übersetzten Inhalte, mit automatisierten Skripts aus einem System in das andere System. Beide Systeme unterstützen den DITA-Standard, und es gibt wenige proprietäre Funktionen, die nicht in das andere System „übersetzt“ werden können.

Die Rolle von Standardisierungsorganisationen bei der Migration von firmeneigenen und proprietären Modellen

Laurent Liscia, Executive Director bei OASIS, hat für CIDM Information Management News, unseren monatlich erscheinenden Newsletter, eine Serie über Standards und Innovation geschrieben.
In CIDM Information Management News, Februar 2010, gibt Liscia einen Überblick über den Verlauf der Entwicklung von Standards. Er erklärt, dass viele der frühen Standards durch von der Regierung genehmigte Institute entwickelt wurden. Beispielsweise wissen wir, dass Behörden der US-Regierung Standards für die Sicherheit am Arbeitsplatz und den sicheren Umgang mit Lebensmitteln aufstellen. Solche de jure oder gesetzlich erforderlichen Standards werden von der Legislative abgedeckt.

Seit einiger Zeit werden Standards nicht nur von der Regierung, sondern von Standardisierungsorganisationen wie OASIS entwickelt, die von den betreffenden Branchen unterstützt werden. Liscia erklärt, dass „1988 … Europa einen visionären und klugen Schritt gemacht hat und eine Standardisierungsorganisation gründete, die nicht nur die Verwaltung von Post und Telekommunikation, sondern auch private Unternehmen in Europa und an anderen Standorten einbezog“.
Innovationen, die firmenintern von Unternehmen entwickelt worden waren ‒ z. B. die Entwicklung von DITA durch IBM ‒, wurden zu einer gemeinsam genutzten und offen zugänglichen Technologiesammlung. Die Standards sind zu einer guten Möglichkeit für uns alle geworden, die Verantwortung und die Kosten für die Produktentwicklung zu teilen.

Natürlich war die Bewegung hin zur Einhaltung von Standards finanziell motiviert. Durch die Zusammenarbeit konnten die Branchenvertreter die Arbeit beim Definieren und Entwickeln einer innovativen Technologie untereinander aufteilen. Bei der Entwicklung des DITA-Standards haben wir genau dieses Ergebnis gesehen. Obwohl der Standard von IBM begonnen wurde, um die eigenen internen Anforderungen zu erfüllen, erlaubte IBM, indem es das ursprüngliche DITA 1.0 OASIS zur Verfügung stellte, dass viele andere Unternehmen diesen Standard nutzten. Die Weiterentwicklung des Standards wird jetzt durch die Arbeit vieler Unternehmen gemeinsam unterstützt.

Das Verteilen der Entwicklungskosten über eine Branche ist jedoch nur einer der Vorteile von Standards. Die Fähigkeit, Inhaltsressourcen von einem Unternehmen zu einem anderen zu übertragen, wurde aufgrund von Übernahmen und Fusionen und durch Unternehmenspartnerschaften sehr wichtig.

Heute können Inhalte nach DITA-Standard

•    In unterschiedlichen Abteilungen und im gesamten globalen Unternehmen verwendet werden
•    In Industriebereichen, die in einer Verbindung mit dem eigenen Unternehmen stehen, gemeinsam genutzt werden
•    Bei Umstrukturierungen von Unternehmen erhalten bleiben

Liscia betont, dass, da „sich die Anzahl der Unternehmen in der Branche vervielfachte, die Kompatibilität unter den vielen erhältlichen Software-Produkten mehr und mehr Wichtigkeit erlangte“.
Auch die Veränderung, dass mehr Kommunikation über das Internet stattfindet und Open-Source-Software verwendet wird sowie die Verwendung von XML als Grundlage haben dazu geführt, dass man heute vermehrt Standards einhält. Alle diese Einflüsse haben geholfen, die Innovation durch DITA zu fördern, denn sie haben neue Möglichkeiten zum Entwickeln und Verwalten von Inhalten eingeführt.
Seit seiner Einführung im Jahr 2006 haben viele Unternehmen den DITA-Standard übernommen. Dadurch werden die Kosten der Implementierung von XML-basiertem strukturiertem Authoring beträchtlich gesenkt.

Die Unternehmen erfahren Unterstützung durch

•    Produktentwickler, die den Standard übernehmen
•    Gut organisierte und effektive Schulungsmöglichkeiten
•    Artikel, Whitepaper, Blogs, Konferenzpräsentationen und Bücher
•    Eine leistungsfähige Gemeinschaft an Beratern und Kollegen

Unternehmen, die ihre Geschäftsführung dazu ermutigen, die Migration zu DITA zu unterstützen, können damit argumentieren, dass die Übernahme eines internationalen Standards, der von einer Gruppe von Branchenvertretern entwickelt wurde, ein vorteilhafter Schritt für das Unternehmen ist. Leitende Manager, die oft in Ingenieurwesen und Softwareentwicklung gearbeitet haben, kennen die Wichtigkeit von Standards. Ihre eigene Arbeit basiert auf Standards, von denen viele auch von der OASIS-Gemeinschaft entwickelt wurden.

Wenn Sie bereit sind, die Übernahme des OASIS DITA-Standards zu empfehlen, sind Sie in guter Gesellschaft!

Autorin:

JoAnn T. Hackos
President Comtech Services, Inc.
Director The Center for Information-Development Management

Dynamic Publishing ist einfach. Man nehme Gestaltungsvorlagen, mit denen die Design-Qualität gesichert wird, speise diese in ein System ein, das die weltweite Zusammenarbeit koordiniert und die Grenze zwischen Layoutern und Fachabteilungen überwindet, und wenn man fertig ist, drückt man auf den „Ausgabe“-Knopf: Schon wird die Markenbotschaft automatisch über alle Kanäle publiziert – von Print über Web bis hin zu iPhone, iPad und Facebook. Das ist alles. So einfach und doch so revolutionär ist Dynamic Publishing. In dieser Cleverprinting-Serie haben wir einen genauen Blick auf die Zutaten für das Publishing der Zukunft geworfen:

- Templates, die mit komplexen Layout-Mechaniken das trockene Papierwissen aus Corporate Design-Manuals zum Leben erwecken und wasserdicht designkonforme Layouts entstehen lassen. In diesen Templates steckt das ganze Know-how der Designer. Sie sind es, die mit der anspruchsvollen und wichtigen Arbeit der Template-Erstellung Dynamic Publishing erst möglich machen.

- Redaktionssysteme, welche die Zusammenarbeit in Teams steuern und Projekte durch Workflows schleusen. Diese Systeme reißen die bestehende Mauer zwischen Grafikern mit Layoutprogrammen und Fachabteilungen mit Office-Programmen ein. Alle Beteiligten arbeiten im selben System und können über webbasierte Oberflächen jederzeit auf den Projektfortgang Einfluss nehmen.

- Automatisierungen greifen das statusbasierte Arbeiten aus Redaktionssystemen auf und wirken in verschiedene Richtungen: Sie erzeugen nicht nur automatisch Verpackungs-Layouts oder Produktdatenblätter, sondern versorgen auch Websites und soziale Netzwerke mit Inhalten. Oder sie bringen neue Nachrichten aufs iPhone oder in das iPad-Magazin. Dieses crossmediale Publishing geschieht automatisiert auf Grundlage von medienspezifisch gestalteten Templates.

Templates, Redaktionssysteme und Automatisierungen sind die Grundvoraussetzungen für Marketing in einer globalisierten Welt und einer sich immer weiter fragmentierenden Mediennutzung. Weil laufend neue Marketingkanäle entstehen, ist eine separate Versorgung mit Inhalten kaum mehr wirtschaftlich zu erledigen. Das gleiche gilt für die Koordination von Projekten in immer größer und internationaler werdenden Teams. Dynamic Publishing setzt hier Potenziale frei und macht das Marketing gleichzeitig zukunftssicher.

In dieser abschließenden Folge der Serie werden die drei Zutaten von Dynamic Publishing zu einem konkreten Projekt miteinander verwoben: Es gibt um eine iPhone Nachrichten-App für die Arosa Bergbahnen im schweizerischen Graubünden. Die App bietet vieles, was für Besucher und Freunde der Skiregion wichtig ist: Wetter, Webcams einen Pistenplan aber auch und vor allem aktuelle Nachrichten. Diese Nachrichten machen den Kern der App aus, sie bieten – oft tagesaktuell – Informationen zu Veranstaltungen, Aktionen oder zum Nachtleben.

Bei der Konzeption der App bildeten die „Nachrichten-Ströme“ das zentrale Element: Sie sollten keine Insellösung sein und im Marketing möglichst wenig Zeit für die Inhaltspflege verursachen. Aus diesem Grund wurde die iPhone App eingebunden in einen nachhaltigen Architekturentwurf – die App wurde, neben den anderen Marketing-Maßnahmen, Teil eines Dynamic Publishing-Systems.

Und das geht so:

1. Für eine Veranstaltung in Arosa werden die Werbemittel erstellt. Dazu sollen vor Ort Plakate aufgestellt und Handzettel verteilt werden. Diese werden im Print-Layoutprogramm erstellt. Dabei kommen natürlich möglichst intelligent gebaute Designvorlagen (Templates) zum Einsatz, die das Corporate Design bereits in weiten Teilen automatisiert berücksichtigen. Die Ausarbeitung dieser Templates ist die Kerndisziplin der Kreativen und Designer. Nur mit gut gebauten Templates kann Dynamic Publishing Wirklichkeit werden.

2. Im klassischen Prozess würden anschließend per E-Mail PDFs hin und her geschickt um Inhalte und Gestaltung abzustimmen. Der Kunde markiert dann im PDF seine Änderungen, schickt diese wieder zurück, wartet auf das korrigierte PDF, kontrolliert seine Änderungen nach, markiert neue Änderungen…
In einer Dynamic Publishing-Umgebung wird der Kunde dagegen direkt in den Prozess eingebunden und kann mit einer webbasierten Oberfläche seine Änderungen direkt anbringen. Sobald das gemacht ist, schickt er die „Aufgabe“ über das System wieder an die Agentur zurück. So wird das Projekt Stück für Stück durch einen Workflow bis hin zur Druckfreigabe gebracht. Es gibt in diesem Prozess keine Ansichts-PDFs und kein langwieriges Nachkontrollieren. Alle arbeiten integriert im selben System. Durch den modularen Aufbau kann gleichzeitig an Projekten gearbeitet werden. Der Kunde schreibt über das Web an den Texten, während der Layouter im Layoutprogramm an der Gestaltung feilt. Die Synchronisation zwischen beiden erfolgt in Echtzeit. Das eröffnet auch tolle Möglichkeiten für besseres Projektmanagement: Fragen wie „Wo hängt der Text gerade?“ oder „Wie weit sind wir schon mit der Anzeige?“ können über das System direkt beantwortet werden und verursachen kein nerviges Projektchaos. Kollaboration über ein Redaktionssystem ist ein neues Arbeitsgefühl, das, einmal erlebt, unverzichtbar wird.

3. Hat das Print-Produkt die Druckfreigabe erreicht, wird automatisch auf Grundlage des Status „Ausgabe“ ein Druck-PDF produziert. Aber nicht nur das. Über eine spezielle „Send to Mobile“ Checkbox im Redaktionssystem wird die Information auch automatisiert auf dem iPhone veröffentlicht. Dabei wird aber nicht einfach 1:1 ein PDF in die App von Arosa transferiert. Vielmehr werden die Inhalte aus der Print-Gestaltung entnommen und in einer optimierten Form auf dem iPhone neu zusammengestellt. Das passiert über eine sog. XML-Transformation, welche die Inhalte von der Gestaltung trennt und diese spezifisch für den jeweiligen Ausgabe-Kanal darstellt. Die Nachricht in der iPhone App wird so quasi zur automatisch erzeugten „Zweit-Verwertung“ des Print-Produkts. Das wichtigste ist aber, dass die Pflege des iPhone Kanals so ohne weiteren Mehraufwand erledigt werden kann.

Übrigens: Aus diesem Print-zentrischen Prozess kann jederzeit ausgebrochen werden. So kann auch die Bereitstellung von iPhone Exclusivinhalten abgebildet werden. Diese können dann natürlich später auch in anderen Kanälen wiederverwendet werden.

Dadurch entsteht eine spannende strategische Perspektive: Genauso wie der iPhone Kanal können zukünftig auch weitere Marketing-Kanäle angebunden werden. Etwa der Internet-Auftritt. Oder weitere Smartphone-Plattformen. Der Aufwand, z.B. eine Android-App zu erzeugen, ist nicht mehr hoch, weil die Nachrichtenströme ja bereits existieren. So wird Inhaltsaufbereitung und -ausgabe aus einem Guss möglich: Der einmal erzeugte Inhalt kann beliebig wieder verwendet werden. Es entstehen Synergieeffekte, gerade weil aufwändige, manuelle und fehleranfällige Copy/Paste-Vorgänge und das Abgleichen zwischen verschiedenen Medien komplett entfallen.

Das Arosa-Projekt ist keine Vision, es ist Realität. Template-basiertes Publishing, neue Kollaboration und crossmediale Ausgabe sind keine Tagträume mehr. Die Philosophien, die hinter Dynamic Publishing stehen, markieren einen Wendepunkt in der Medienproduktion. Zukünftige Projekte werden weniger in den eingefahrenen Prozessen des klassischen Desktop Publishing stattfinden, sondern mehr in den neuen Paradigmen von Dynamic Publishing. Eine große Chance für die Kreativbranche, deren Arbeit wichtiger, anspruchsvoller und weniger austauschbar wird. Durch die neu gewonnene Agilität im Marketing entstehen auf Kunden- und Agenturseite langfristig Zeit- und Kosteneinsparungen und so auch Marktvorteile. Alles was Sie für zukunftssicheres Publishing brauchen ist da – Packen Sie’s an!

Autor: Georg Obermayr

Quark veröffentlicht  in Kooperation mit Cleverprinting alle Teile der erfolgreichen Serie von Georg Obermayr auf dem Dynamic Publisher Blog:

Teil 1: Einführung (bereits erschienen)
Teil 2: Web-to-Print (bereits erschienen)
Teil 3: Redaktionssysteme (bereits erschienen)
Teil 4: Integrierte Publishing-Systeme
Teil 5: Fazit

Der Cleverprinting-Newsletter bietet neben diesem Artikel viele weitere Informationen rund um das Thema DTP. Mit 14.000 Abonnenten ist er einer der meistgelesenen Newsletter der Branche (www.cleverprinting.de/newsletter).

—

Eine Vielzahl an Experten bei Quark ist intensiv damit beschäftigt, Dynamic- und Digital-Publishing-Software zu entwickeln. Als Teil dieser Arbeit sprechen sie mit Analysten, den Medien und Kunden. Sie alle bestätigen: Die Suche nach einer geeigneten Möglichkeit für das digitale Publishing ist für Unternehmen derzeit eines der dringendsten Anliegen, damit sie schon bald über die neuesten digitalen Geräte mit ihren Kunden in Kontakt treten können. Der große Bedarf ist nachvollziehbar –  schließlich sagt Forrester voraus, die  Verkaufszahlen von Tablets in den USA würden sich “im Jahr 2011 auf 24,1 Millionen Geräte verdoppeln.”

Der digitale Boom stellt für viele Unternehmen eine große Herausforderung dar. Das Umstellen veralteter Publishing-Prozesse hat oberste Priorität und kann nicht mehr verschoben oder ignoriert werden. Medienunternehmen wie auch andere Unternehmen, die Inhalte veröffentlichen, unterstützten ursprünglich neben Printmedien auch das Web, indem sie einfach mehr Ressourcen zur Verfügung stellten ‒ in einigen Fällen ein vollständiges zusätzliches Team. Aber nach der Einführung von eReadern, Smartphones und Tablets können es sich die meisten Unternehmen nicht leisten, noch mehr Geld auszugeben und weitere Ressourcen zur Verfügung zu stellen, um diesen neuen Kanal zu erreichen.

Die Sache ist nicht ganz unkompliziert, denn es geht nicht mehr nur darum, Inhalte über ein neues Medium zur Verfügung zu stellen: Es geht um ein neues Kundenerlebnis. Was sind die Erwartungen der Kunden?

1. Sie wollen, dass relevante Informationen auf allen ihren Geräten zur Verfügung stehen ‒ Web, Print, digitale Geräte.
2. Sie wollen diese Informationen sofort zur Hand haben, genau wie ihre mobilen Geräte, die sie jederzeit und überall bei sich haben.
3. Sie wollen interagieren und nicht nur lesen.

Dynamic Publishing:  Eine clevere Lösung

Vor einigen Jahren definierte Quark das Dynamic Publishing wie folgt: „Professionelles Design trifft auf automatisiertes Cross Media Publishing“. Sehen wir uns an, wie diese Herangehensweise den Unternehmen hilft, den Informationshunger der Kunden zu stillen:

1.    Um das Cross Media Publishing kosteneffektiv umzusetzen, müssen Unternehmen Möglichkeiten finden, ihre Prozesse zu optimieren und zu automatisieren. Dies erfordert eine Publishing-Plattform, die beim Erstellen von Inhalten eine Zusammenarbeit in Echtzeit unterstützt, die für die Ausgabe in allen Medienarten geeignet ist und die einen automatisierten Prozess zum Ausgeben dieser Inhalte ermöglicht. Diese Plattform muss flexibel sein, so dass sie sich den schnellen technologischen Veränderungen anpassen kann, die zum Beispiel der Tablet-Boom mit sich bringt.

2.    Um Informationen einheitlich, präzise und schnell über alle Medien auszugeben, müssen Unternehmen Inhalte weitestmöglich wiederverwenden und dem jeweiligen Medium anpassen. Der erste Schritt hin zum Dynamic Publishing ist es, den Prozess mit der Erstellung von Inhaltskomponenten zu beginnen, die beliebig oft automatisiert zusammengestellt und wiederverwendet werden können. Dafür ist nicht nur XML erforderlich, sondern auch eine einfache und vertraute Methode, damit der normale Microsoft Word Anwender dieses XML erstellen und bearbeiten kann – ohne sich umfassend mit XML auszukennen.

3.    Um die Möglichkeiten von digitalen Geräten optimal zu nutzen, müssen Unternehmen attraktive Erlebnisse konzipieren und ausgeben können, so dass die Verbraucher sich interaktiv durch die Inhalte bewegen können und interagieren können. Die Kommunikation wird interaktiver, visuelles Design wird mit Sound, Videos sowie mit anderen Funktionen kombiniert, um ein markenspezifisches Benutzererlebnis zu entwickeln.

Das Tablet kam aus dem Nichts, und niemand hat mit dem Boom in diesem Ausmaße gerechnet ‒ aber weil Quark sich entschlossen hat, eine Strategie des Digital Publishing zu verfolgen, ist das Unternehmen gut vorbereitet. Wenn Sie also nach Möglichkeiten suchen, sich für das digitale Zeitalter zu rüsten, kann Quark Sie dabei unterstützen.