Content Management Systeme ZURÜCK zu CMS Content Management Systeme „CMS sind Softwaresysteme für das Management von Internetinhalten. Sie unterstützen organisatorische Ablaufstrukturen, die mit gewachsenen Internet- und Intranetauftritten einhergehen.“ Beispielhafte Ablaufstruktur für die Aktualisierung von Informationen auf einem Internet-/Intranetserver: Manager bemerkt dass eine bestimmte Seite nicht aktualisiert wurde und wünscht ein Update mit neuen Infos Manager schickt E-Mail an Redakteur dieser Seite/Rubrik Redakteur holt sich Kopie der Seite auf den lokalen Rechner und nimmt Änderungen vor ( Problem der zeitgleichen Bearbeitung!) Probleme ersichtlich: Hoher Bedarf an Kommunikation und Koordination (3 verschiedene Institutionen werden durchlaufen) Zeitintensiv (Änderungen und Neuerungen gehen ohne maschinelle Unterstützung oft nur mit Zeitverzug online) Ohne Webmaster geht nichts ( Überlastung) Noch längere Reaktions- und Durchlaufzeiten bei Übertragung der Arbeiten an die externe Werbeagentur HTML-Kenntnisse und Kenntnisse über die Struktur der Site sind vom Verantwortlichen (Redakteur) notwendig  Bedarf an Software für das Management von Internetinhalten & des Content-Workflow (Erstellung, Pflege, Qualitätssicherung und Freigabe der Inhalte) Zyklus beginnt erneut nicht genehmigt Seite wird auf den Server gestellt Webmaster wird benachrichtigt dass neue Seite bereit steht Manager prüft neuen Inhalt. Entweder die Seite geht zurück an Redakteur oder sie kann online gehen Nach Erledigung der Änderungen wird die Seite auf Zwischenserver gestellt genehmigt Manager Redakteur Webmaster

Probleme ersichtlich: Hoher Bedarf an Kommunikation und Koordination (3 verschiedene Institutionen werden durchlaufen) Zeitintensiv (Änderungen und Neuerungen gehen ohne maschinelle Unterstützung oft nur mit Zeitverzug online) Ohne Webmaster geht nichts ( Überlastung) Noch längere Reaktions- und Durchlaufzeiten bei Übertragung der Arbeiten an die externe Werbeagentur HTML-Kenntnisse und Kenntnisse über die Struktur der Site sind vom Verantwortlichen (Redakteur) notwendig  Bedarf an Software für das Management von Internetinhalten & des Content-Workflow (Erstellung, Pflege, Qualitätssicherung und Freigabe der Inhalte)

Webmaster, Supervisor (organisatorische Administrationsfunktion) Einsatzziele von CMS Anbindung und Beteiligung dezentraler Inhalte-Lieferanten Entlastung der Administratoren bei der Pflege und Wartung der Inhalte Durchlaufzeit verkürzen durch Dezentralisierungsgedanke Fach- abteilung 4 Tochtergesell- schaft XYZ Herr Müller Fach- abteilung 3 Internet- oder Intranetauftritt Vielzahl von Dateien und Dokumenten Fach- abteilung 2 Zu 1.: (mehrere Mitarbeiter in den Fachabteilungen ohne HTML-Kenntnisse, externe DV-Systeme z.B. für dynamische Webseitengenerierung bei Datenbankabfragen) Zu 3.: und damit höhere Aktualität gewährleisten Externe DV-Systeme ERP-System (z.B. SAP) Datenbanken Buchhaltungssystem Fach- abteilung 1 Webmaster, Supervisor (organisatorische Administrationsfunktion)

Spezifikation von Content Trennung von Content in Struktur, Darstellung und Inhalt: Struktur von Content am Beispiel einer Presseinformation: Presseinformation Dar-stellung, Layout Struktur Titel Kurzzusammenfassung Detailinformation (Text) Verf. Datum Inhalt (Rohdaten) Vorname Nachname Telefon E-Mail Postanschrift Struktur: Inhaltliche Definition der Einzelinformationen und deren Abfolge bzw. Verschachtelung Was ist Content?  Stellen wir uns eine Presseinformation dar, wie sie auf einer Webseite präsentiert werden könnte. Wir erkennen eine Struktur: Titel, Kurzzusammenfassung etc. (Bild) Es gibt unterschiedliche Darstellungsmöglichkeiten der Presseinformation: Papier, Web etc. (Bild) ...und den Rohinhalt an sich (z.B. Telefonnummer des ASP)  Content = Nicht nur der Inhalt, der sich dem Betrachter optisch am Bildschirm präsentiert muss im Zusammenhang mit CMS differenzierter betrachtet werden: Content als Summe von Struktur, Darstellungsform (Layout) und Inhalt Die Zerlegung und damit seperate Datenhaltung dieser 3 wesentlichen Bestandteile von Content ist notwendig, insbesondere im Hinblick auf die Möglichkeit der automatisierten Weiterverarbeitung der Informationen (Stichwort „Single Source Multiple Media“) oder Wiederverwendung (Content Syndication  Fabian) Gute CMS halten Rohdaten idealerweise in XML Oft läßt sich der Unterschied von Inhalt und Struktur nur mit menschlichem Auge erkennen. Ein Computer hätte z.B. bei folgendem Beispiel reichlich Mühe, diesen Unterschied zu analysieren: Bei Formatierungen in Word direkt im geschriebenen Text und beispielsweise eine Überschrift direkt im Text fett macht (evtl. etwas größer mit der Werkzeugleiste oben), dann erkennt menschliche Betrachter mühelos, dass es sich bei dem fetten, in größerer Schrift geschriebenem Text um eine Überschrift handelt. Der Computer (hier CMS) allerdings kann nicht so problemlos diesen optisch hervorgehobenen Text als Titel erkennen und verarbeiten. Dem CMS fehlt die maschinell interpretierbare Metainformation, dass es sich hier um eine Überschrift handelt. Hätte der Autor diesem Text die Formatvorlage „Überschrift1“ zugewiesen, würde das System den Text eindeutig als Überschrift identifizieren und entsprechend weiterbearbeiten können (z.B. in einer Übersichtsseite einblenden). Darstellung von Content am Beispiel der Presseinformation: Ausdruck auf Papier: Inhalt wird layoutet für optimale Ausfüllung einer A4-Seite, entsprechend der Unternehmens-CI Veröffentlichung im Web: Mit anderem Stylesheet wird derselbe Inhalt in weboptimierter Weise in HTML publiziert (angepasst an Web-CI) Darstellung: formale Beschreibung zur Repräsentation auf einem Ausgabemedium (Web, Print, Handy-Display etc.) Stylesheets enthalten Anweisungen, wie der Inhalt formatiert und positioniert werden soll

Was ist Content?  Stellen wir uns eine Presseinformation dar, wie sie auf einer Webseite präsentiert werden könnte. Wir erkennen eine Struktur: Titel, Kurzzusammenfassung etc. (Bild) Es gibt unterschiedliche Darstellungsmöglichkeiten der Presseinformation: Papier, Web etc. (Bild) ...und den Rohinhalt an sich (z.B. Telefonnummer des ASP)

 Content = Nicht nur der Inhalt, der sich dem Betrachter optisch am Bildschirm präsentiert muss im Zusammenhang mit CMS differenzierter betrachtet werden: Content als Summe von Struktur, Darstellungsform (Layout) und Inhalt Die Zerlegung und damit seperate Datenhaltung dieser 3 wesentlichen Bestandteile von Content ist notwendig, insbesondere im Hinblick auf die Möglichkeit der automatisierten Weiterverarbeitung der Informationen (Stichwort „Single Source Multiple Media“) oder Wiederverwendung (Content Syndication  Fabian) Gute CMS halten Rohdaten idealerweise in XML

 Content = Oft läßt sich der Unterschied von Inhalt und Struktur nur mit menschlichem Auge erkennen. Ein Computer hätte z.B. bei folgendem Beispiel reichlich Mühe, diesen Unterschied zu analysieren: Bei Formatierungen in Word direkt im geschriebenen Text und beispielsweise eine Überschrift direkt im Text fett macht (evtl. etwas größer mit der Werkzeugleiste oben), dann erkennt menschliche Betrachter mühelos, dass es sich bei dem fetten, in größerer Schrift geschriebenem Text um eine Überschrift handelt. Der Computer (hier CMS) allerdings kann nicht so problemlos diesen optisch hervorgehobenen Text als Titel erkennen und verarbeiten. Dem CMS fehlt die maschinell interpretierbare Metainformation, dass es sich hier um eine Überschrift handelt. Hätte der Autor diesem Text die Formatvorlage „Überschrift1“ zugewiesen, würde das System den Text eindeutig als Überschrift identifizieren und entsprechend weiterbearbeiten können (z.B. in einer Übersichtsseite einblenden).

Technik: STAGING CMS Templates, Layout FTP-Export =STAGING Client Redaktions-Server Web-Server Web- Browser Web- Browser HTML LOGIN HTML-Dokumente Kunde/Leser Autor Inhalte (in XML) werden auf seperatem Server erstellt und verwaltet. Zu einem bestimmten Zeitpunkt wird ein Generat aus statischen HTML-Seiten erzeugt (=STAGING) und auf den Webserver exportiert. Dies kann zeitgesteuert oder ereignisgesteuert für voneinander unabhängige Bereiche der Website erfolgen. Export kann in vordefinierten Zyklen und partiell für Inhaltsrubriken auf dem Webserver erfolgen  schnelle Performance, da keine Datenbankabfragen zum Zeitpunkt der Anfrage nach der Webseite gemacht werden und die Webseiten so nicht erst noch generiert werden müssen  geeignet für Darstellung statischer Info, die zyklisch geändert wird Daten Schnelle Performance Export partiell in vordefinierten Zyklen CMS Firewall Quelle: Fraunhofer IAO „Content Management Systeme: Dokumentation“

Inhalte (in XML) werden auf separatem Server erstellt und verwaltet. Zu einem bestimmten Zeitpunkt wird ein Generat aus statischen HTML-Seiten erzeugt (=STAGING) und auf den Webserver exportiert. Dies kann zeitgesteuert oder ereignisgesteuert für voneinander unabhängige Bereiche der Website erfolgen. Export kann in vordefinierten Zyklen und partiell für Inhaltsrubriken auf dem Webserver erfolgen  schnelle Performance, da keine Datenbankabfragen zum Zeitpunkt der Anfrage nach der Webseite gemacht werden und die Webseiten so nicht erst noch generiert werden müssen  geeignet für Darstellung statischer Info, die zyklisch geändert wird

Technik: Live – CMS Dynamisch generierte Webseiten mit Bewegungsdaten aus anderen DV-Systemen Erzeugung der Webseiten zum Zeitpunkt des Aufrufs aus Vorlagen mit Platzhaltern für die Datenbankinhalte LIVE-Zugriff = zeitaktueller Zugriff auf die Daten eines DV-Sytems Templates, Layout 5 Client 1 2 Redaktions-server 3 Web-Server Web- Browser Browser stellt Anfrage an Web-Server Web-Server reicht Anfrage an Application Server (Middleware) weiter Application Server greift auf Daten des DBMS zu (Datenbankabfrage) Datenbank gibt Ergebnis an Application Server zurück Layoutinformationen und Strukturinformationen (Templates) werden von der Middleware Applikation mit dem Abfrageergebnis gefüllt Application Server gibt fertige HTML-Seite an Web-Server Web-Server reicht HTML-Seite an Browser weiter Für Einbindung von Bewegungsdaten aus anderen DV-Systemen über das CMS (z.B. Buchantwortseite von Amazon oder aktuelle Preisangaben aus Warenwirtschaftssystemen) = dynamisch generierte Webseiten Webseiten werden bei Abruf vom Client dynamisch aus Vorlagen mit Platzhaltern für die Datenbankinhalte und den Datenbankinhalten aus dem DBMS generiert Bei jedem Aufruf wird eine Webseite zeitaktuell mit den entsprechenden Daten an den Anfrager ausgeliefert. Die Webserveranfrage ist damit ein LIVE-ZUGRIFF auf die Daten eines beteiligten DV-Systems. Daten werden im CMS idealerweise in XML abgelegt. Warum? HTML HTML Inhalt Datenbank 7 6 4 Kunde/Leser CMS Quelle: Fraunhofer IAO „Content Management Systeme: Dokumentation“ Quelle: Fraunhofer IAO „Content Management Systeme: Dokumentation“

-- Browser stellt Anfrage an Web-Server Web-Server reicht Anfrage an Application Server (Middleware) weiter Application Server greift auf Daten des DBMS zu (Datenbankabfrage) Datenbank gibt Ergebnis an Application Server zurück Layoutinformationen und Strukturinformationen (Templates) werden von der Middleware Applikation mit dem Abfrageergebnis gefüllt Application Server gibt fertige HTML-Seite an Web-Server Web-Server reicht HTML-Seite an Browser weiter

-- Für Einbindung von Bewegungsdaten aus anderen DV-Systemen über das CMS (z.B. Buchantwortseite von Amazon oder aktuelle Preisangaben aus Warenwirtschaftssystemen) = dynamisch generierte Webseiten Webseiten werden bei Abruf vom Client dynamisch aus Vorlagen mit Platzhaltern für die Datenbankinhalte und den Datenbankinhalten aus dem DBMS generiert Bei jedem Aufruf wird eine Webseite zeitaktuell mit den entsprechenden Daten an den Anfrager ausgeliefert. Die Webserveranfrage ist damit ein LIVE-ZUGRIFF auf die Daten eines beteiligten DV-Systems.

Basistechnologien: XML Warum XML? Content in medienspezifischen Formaten (besonders HTML) enthält keine Informationen über den Inhalt und dessen Bedeutung (Metainformationen) und ist somit ungeeignet für die maschinelle Weiterverarbeitung. Quellcode des ersten Datensatzes in HTML: <TR> <TD>Der Süden schwitzt</TD> <TD>Sommer in Hochform</TD> <TD>Mit bis zu 34 Grad im Süden wird...</TD> <TD>Frieder Müller</TD> <TD>Dettenhausen</TD> </TR> Quellcode des ersten Datensatzes in XML: <datensatz> <header>Der Süden schwitzt</header> <subheader>Sommer in Hochform</subheader> <text>Mit bis zu 34 Grad im Süden...</text> <author>Frieder Müller</author> <date>26. Juni 2001</date> </datensatz> Bsp. 1 (Folie): Wenn aus einer Datenbank ein Datensatz mit unterschiedlichen Datenfeldern generiert und automatisch in HTML konvertiert wird, gehen wichtige Informationen über die Bedeutung der einzelnen Felder verloren. So ist z.B. die Bedeutung des Wertes „Sommer in Hochform“ nur anhand der Spaltenüberschrift der Tabelle für einen menschlichen Betrachter als Subheader identifizierbar, für einen Computer hingegen ist es nicht mehr möglich, diesen Kontext zu erfassen, da die mit dem Wert verkoppelte Metainformation fehlt. Analog: Wenn unser Word-Dokument in HTML umgewandelt wird, dann bleibt die Ueberschrift 1 zwar optisch für unser Auge erkennbar, aber eine maschinelle Weiterverarbeitung schwierig, da ausser der Formatierung (z.B. fett,arial,12pt) nichts über die Bedeutung des Inhalts beschrieben ist (dass es nämlich eine Überschrift ist) Die maschinelle automatisierte Weiterverarbeitung der Daten im CMS muss möglich sein. Dazu müssen Daten aus einer Datenbank (CMS legt Daten in Datenbank ab) in andere Anwendungen übernommen werden. Hierfür wird ein Austauschformat benötigt, das die Felder der Tabelle sowie deren Datensätze beschreiben kann. Hier kommt XML ins Spiel. Mit XML als als Dokumentenbeschreibungssprache kann z.B. die Bedeutung des Textes „Sommer in Hochform“ mit Hilfe von TAGS (Auszeichnern) mitgegeben werden. Durch die Auszeichnung der Rohinhalte in TAGS ist eine inhaltliche Beschreibung der Daten vorhanden und bleibt zu jedem Zeitpunkt beim Empfänger erhalten  problemlose maschinelle Weiterverarbeitung nach der Distribution der Informationen. Werden die Daten also mit XML beschrieben, bleiben die Metainfos erhalten und der Computer kann z.B. den Text „Sommer in Hochform“ als Subheader identifizieren und weiterverarbeiten. Metainformation über die Bedeutung der Werte ist verlorengegangen Metainformationen über die Bedeutung der Werte bleibt aus der Datenbank erhalten

Bsp. 1 (Folie): Wenn aus einer Datenbank ein Datensatz mit unterschiedlichen Datenfeldern generiert und automatisch in HTML konvertiert wird, gehen wichtige Informationen über die Bedeutung der einzelnen Felder verloren. So ist z.B. die Bedeutung des Wertes „Sommer in Hochform“ nur anhand der Spaltenüberschrift der Tabelle für einen menschlichen Betrachter als Subheader identifizierbar, für einen Computer hingegen ist es nicht mehr möglich, diesen Kontext zu erfassen, da die mit dem Wert verkoppelte Metainformation fehlt.

Analog: Wenn unser Word-Dokument in HTML umgewandelt wird, dann bleibt die Ueberschrift 1 zwar optisch für unser Auge erkennbar, aber eine maschinelle Weiterverarbeitung schwierig, da ausser der Formatierung (z.B. fett,arial,12pt) nichts über die Bedeutung des Inhalts beschrieben ist (dass es nämlich eine Überschrift ist) Die maschinelle automatisierte Weiterverarbeitung der Daten im CMS muss möglich sein. Dazu müssen Daten aus einer Datenbank (CMS legt Daten in Datenbank ab) in andere Anwendungen übernommen werden. Hierfür wird ein Austauschformat benötigt, das die Felder der Tabelle sowie deren Datensätze beschreiben kann.

Hier kommt XML ins Spiel Hier kommt XML ins Spiel. Mit XML als als Dokumentenbeschreibungssprache kann z.B. die Bedeutung des Textes „Sommer in Hochform“ mit Hilfe von TAGS (Auszeichnern) mitgegeben werden. Durch die Auszeichnung der Rohinhalte in TAGS ist eine inhaltliche Beschreibung der Daten vorhanden und bleibt zu jedem Zeitpunkt beim Empfänger erhalten  problemlose maschinelle Weiterverarbeitung nach der Distribution der Informationen. Werden die Daten also mit XML beschrieben, bleiben die Metainfos erhalten und der Computer kann z.B. den Text „Sommer in Hochform“ als Subheader identifizieren und weiterverarbeiten.

Basistechnologien: XML Warum XML? 2. Feste Kopplung des Rohinhaltes mit Formatierungsanweisungen in medienspezifischen Formaten (besonders HTML) steht dem Prinzip der Dreiteilung des Content entgegen. Mit XML und XSL kann diese Dreiteilung technisch realisiert werden. Struktur, Rohinhalt, Darstellung Struktur Rohinhalt Darstellung XML Document Type Definition XML Daten in Tags XSL XSL-Stylesheets Konvertierung von XML in Ausgabeformate: PDF, PDA, WML, HTML etc. Formatierungs-anweisungen Rohinhalt XML-Dokument: Document Type Definition: jedes XML-Dokument enthält eine inhaltliche Definition der Datenelemente und Attribute, deren Auftreten, Reihenfolge oder Verschachtelung Daten in Tags: der eigentliche Inhalt wird entsprechend den Regeln der Document Type Definition aufgebaut und beschrieben. XSL-Stylesheets: zur Darstellung und formalen Beschreibung auf einem Ausgabemedium kommen Stylesheets in XSL zum Einsatz. Der Inhalt des XSL-Stylesheet bestimmt, welches Format aus der XML-Datei generiert wird. HTML XML / XSL

XML-Dokument: Document Type Definition: jedes XML-Dokument enthält eine inhaltliche Definition der Datenelemente und Attribute, deren Auftreten, Reihenfolge oder Verschachtelung Daten in Tags: der eigentliche Inhalt wird entsprechend den Regeln der Document Type Definition aufgebaut und beschrieben. XSL-Stylesheets: zur Darstellung und formalen Beschreibung auf einem Ausgabemedium kommen Stylesheets in XSL zum Einsatz. Der Inhalt des XSL-Stylesheet bestimmt, welches Format aus der XML-Datei generiert wird.

Transformation von XML mit XSL Umwandlung von XML-Daten in medienspezifische Ausgabeformate mit XSL-Stylesheets: XSL-File für HTML XML - File XSL-File für WML Input XSL-File für PDF „Single Source Multiple Media“ etc... XSL-Prozessor Von einem XSL-Prozessor (z.B. MSIE 5.0 oder IBM XSL-Editor) werden die strukturierten XML-Daten zusammen mit den Darstellungsinformationen im XSL-File verarbeitet und ein entsprechendes Ausgabeformat generiert (z.B. HTML oder PDF). So werden XML-Daten mit Hilfe der eXtensible Stylesheet Language in medienspezifische Ausgabeformate (HTML für Internet/Browser, WML für WAP-Handys, Print etc.) umgewandelt. Wie sieht das Ganze nun in der Realität aus?  Präsentation einer XML- und XSL-Datei sowie die praktische Umsetzung des XSL-Transformationsprinzip anhand des IBM XSL-Editors. HTML WML etc. Output PDF Print

Von einem XSL-Prozessor (z. B. MSIE 5 Von einem XSL-Prozessor (z.B. MSIE 5.0 oder IBM XSL-Editor) werden die strukturierten XML-Daten zusammen mit den Darstellungsinformationen im XSL-File verarbeitet und ein entsprechendes Ausgabeformat generiert (z.B. HTML oder PDF). So werden XML-Daten mit Hilfe der eXtensible Stylesheet Language in medienspezifische Ausgabeformate (HTML für Internet/Browser, WML für WAP-Handys, Print etc.) umgewandelt. Wie sieht das Ganze nun in der Realität aus?  Präsentation einer XML- und XSL-Datei sowie die praktische Umsetzung des XSL-Transformationsprinzip anhand des IBM XSL-Editors.

Marktübersicht CM-Systeme

XML-Template Quellcode eines XML-Templates mit Platzhaltern ZURÜCK zu CMS