«Content First Publishing» setzt voraus, dass Inhalt neutral und unabhängig des späteren Ausgabekanals erfasst wird.
Zum Erfassen von neutralem Inhalt haben sich die beiden Datenformate XML und HTML etabliert. Was ist nun besser? Während «HTML Authoring» heute noch massiv günstiger ist (vor allem den Preisen der Werkzeuge und den günstigen Entwicklern geschuldet), ist XML anspruchsvoller (den Freiheiten geschuldet), kann jedoch weit besser automatisiert werden. Ist eines nun besser? Nein. Anforderungen und Budget bestimmen die Technologie.
Hier eine kleine Gegenüberstellung von HTML und XML in Bezug auf «Content First Publishing», respektive die Erfassung von Inhalt für «Content First Publishing». Die Liste ist nicht vollständig, gerne im Kommentar unten ergänzen.
| HTML Authoring | XML Authoring |
| Weit verbreitet, viel Wissen vorhanden | Wenig Wissen vorhanden |
| Nicht erweiterbar (Vorgabe W3C) | Erweiterbar gemäss eigenen Bedürfnissen |
| Keine eigenen Datenmodelle (nur valides HTML) | Datenmodelle sichergestellt durch Schema, DTD, Schematron (live Validierung beim Erfassen), standardisierte Datenmodelle (parsX, DITA…) |
| Beschränkte Automation | Kaum Grenzen in der Automation |
| Günstige Publishing-Systeme (auch OpenSource) | Aufwändige Publishing-Systeme |
| Endformat, bereits optimiert für den Ausgabekanal Screen | Speicherung von Inhalt (reine Semantik) |
Und in zwei Sätzen
XML wurde erfunden, um Daten zu speichern. HTML wurde erfunden, um Daten darzustellen.
Vorsicht Etikette
Beim Evaluieren eines neuen Systems musst du immer penetrant nachfragen, ob nun HTML oder XML verarbeitet wird. Auf den ersten Blick ist das nämlich oft nicht ersichtlich, kann aber auf die späteren Automationsmöglichkeiten und den Preis massiven Einfluss haben. Leider ist auch nicht überall XML drin, wo XML draufsteht. Damit meine ich: Es gibt Hersteller, welche HTML in ein XML-Paket stecken. Legitim, wenn es vom Prozess her reicht und den Preis niedriger hält. Aber nur die Etikette.
3 Antworten
Anmerkung
Bei Medien-neutralem Content Spielt die Schrift, besonders bei technisch/wissenschaftlichen Inhalten eine Rolle, dass die benötigten Sonderzeichen in den gewünschten Schriften vorhanden sind.
Bei der Erfassung kann man z.B. die Arial Unicode MS oder die DejaVu Sans verwenden, ist ja egal wie es aussieht.
In den jeweiligen Ausgabe muss man sehen, dass die verwendeten Zeichen auch vorhanden sind!
Besonders visuell orientieren Designern wird es schwer fallen Schriften nach dem Zeicheninhalt auszuwählen.
MIr scheint der grosse Schritt gar nicht so sehr die Bereitstellung von Content in XML oder HTML zu sein. Wesentlich mehr Arbeit muss man darin stecken, überhaupt Content First zu denken. Einen Inhalt erstellen ohne irgendeinen Hinweis auf das Ausgabeformat ist sehr ungewohnt und braucht Übung. Und man muss sich drauf einlassen.
Roman, einerseits und andererseits bin ich geneigt zu sagen. Es ist wohl generell nicht möglich, sich Inhalt unabhängig von irgend einer Form der Darstellung vorzustellen. Ein Lehrbuchverlag sieht jeden Inhalt als Lehrbuch mit bestimmtem Layout. Würde er das als Video sehen, würde er Lernvideos produzieren.
Sicher ist es ungewohnt, Inhalt zu erstellen, ohne sich eine bestimmte Form der Darstellung vorzustellen. Es genügt aber doch schon, an mehere Darstellungsarten zu denken: Videos, Vorträge, Folien, Texte in unterschiedlicher Form und Interaktionen, die den Nutzern Wahlmöglichkeiten und Rückmeldungen bieten. Es fehlt allerdings das entsprechende Geschäftsmodell.
HTML kombiniert mit CSS ist dabei, sich immer mehr von XML zu entfernen. Insoweit ist die technische Frage, ob universell verwendbare Inhalte als HTML oder XML gespeichert werden sollten schon wichtig, weil HTML die Darstellungsmöglichkeiten einschränkt.