"Der Wissenschaftsrat empfiehlt den Trägereinrichtungen die umfassende und langfristige Archivierung qualitätsgesicherter und für die jeweilige wissenschaftliche Gemeinschaft langfristig relevanter Daten."
Empfehlung zu Forschungsinfrastrukturen in den Geistes- und Sozialwissenschaften, Wissenschaftsrat, Berlin, 28.01.2011, S.57f.

XForms zur Erstellung, Bearbeitung und Anzeige von CMDI-Metadaten

Details
Erstellt am Montag, 23. Januar 2012 17:38
Geschrieben von Thorsten Trippel

Zur Erstellung, Bearbeitung und Anzeige von CMDI-Metadaten verwenden wir XForms, einen W3C-Standard, mit dessen Hilfe hochstrukturierte Formulare z.B. in HTML-Seiten eingebunden werden können. Um XForms in beliebigen Browsern darstellen zu können, verwenden wir serverseitig eine Software-Bibliothek, mit deren Hilfe wir die eingebetteten XForms in Standard-HTML übersetzen und über das WWW ausliefern. Die Bibliothek, die wir verwenden, ist betterFORM, die innerhalb eines Tomcat läuft. betterFORM ist für uns die perfekte XForms-Bibliothek: Serverseitig können wir betterFORM so einsetzen, wie es ist, es aber auch in unsere eigenen Webapplikationen einbinden. Durch die serverseitige Verarbeitung öffnen wir keine neuen Sicherheitslücken. Die Verarbeitung läuft auch bei komplexen Datenmodellen schnell und das User-Interface lässt sich nach unseren Wünschen gestalten. Was braucht man mehr, wenn man komplexe XML-Dokumente mittels Formularen bearbeiten können will? Im Folgenden beschreiben wir, wieso wir XForms mit betterFORM einsetzen.

Wir haben an anderer Stelle (CMDI: Metadatenschema für Sprachressourcen, Using CMDI (CLARIN-D Workshops), Nijmegen 09-09-2011 ) bereits beschreiben, warum CMDI für die Beschreibung von Sprachressourcen ein nützliches und notwendiges Format ist, das die nötige Flexibilität mitbringt, um unterschiedliche Datentypen adäquat beschreiben zu können. Eine Herausforderung, die man aber bei einem sehr flexiblen Datenmodell hat, das zudem noch sehr reiche Beschreibungen ermöglicht, ist die Erstellung und Bearbeitung von Metadatendokumenten.

CMDI-Daten sind gewöhnlich reiche, hierarchische XML-Dateien. Man weiß damit nicht unbedingt im Voraus, wie viele Felder es gibt, aber man weiß, dass die Felder in bestimmten hierarchischen Zusammenhängen existieren.

Modelle zur Bearbeitung von Metadatendokumenten

Die einfachste Möglichkeit, normalerweise für eine einfache Handhabung von Metadaten zu sorgen, ist ein Formular, in dem es für jede Datenkategorie genau ein Feld gibt. Wenn man also die klassischen 15 Datenkategorien von Dublin Core nähme, hätte man also ein Formular mit 15 Feldern. Da aber z.B. Aufsätze mehr als einen Autor haben können, ist es möglich, jedes Feld auch mehrfach anzulegen, was das Datenmodell bereits verkompliziert.

In einem Index wäre es daher möglich, ein Datenmodell zu wählen, das im Prinzip bei 15 Feldern 15 Tabellen verwendet: für jede Datenkategorie gäbe es eine Tabelle, der Identifikator könnte als Primärschlüssel dienen. Damit würde ein Eintrag z.B. in der Autoren-Datenbank eine Liste aller Autoren beinhalten und eine Liste der Primärschlüssel, an denen sie mitgearbeitet haben. Nimmt man dann alle Werte, die den Primärschlüssel beinhalten, könnte man den Eintrag für ein bestimmtes Werk (mit dem jeweiligen Identifikator) erhalten. Mittels dieses Verfahrens ließe sich z.B. ein relationales Modell verwenden. Einzelne Felder werden als Array interpretiert und entsprechend verarbeitet. Auf diese Weise kann eine Art Tabelle als User Interface verwendet werden.

Gibt es aber, wie in CMDI, auch die Möglichkeit, Datenkategorien zusammen zu bündeln und hierarchisch darzustellen, eignet sich dieses Verfahren weniger für die Erstellung, denn man müsste jedes Mal erst ermitteln, wie viele Felder es überhaupt gibt, in welchen Abhängigkeiten diese zueinander stehen und bei der Einfügung von einem Feld möglicherweise weitere Felder ergänzen. Dies kann man natürlich mit Software lösen. Aber es gibt noch mindestens eine andere Möglichkeit.

XFORMS ist ein Webstandard, der in Verbindung mit XML-Dokumenten verwendet werden kann. Dabei wird ein XML-Dokument an sich als Datenmodell verwendet und direkt modifiziert. Es wird spezifiziert, welche Teilbäume des XML-Baumes mit welcher Art von Formular editiert werden soll. So ein XForms-Formular kann dann in eine XHTML-Seite eingebunden werden. Der Autor der Seite braucht sich nicht um die Verarbeitung des DOM für das XML-Dokument kümmern, Ein- und Ausgabe sind auch definiert. Und wenn man XHTML als Host-Dokument, also zur Anzeige, verwendet, ist auch die Frage des User-Interfaces einfach: man nimmt einen Browser und gestaltet die Seite mittels CSS, HTML und kann sogar noch JavaScript einsetzen.

Einbinden von XForms in XTHML

Das klingt erst einmal gut, aber aktuelle Browser unterstützen kein XForms. Und wenn man sich überlegt, dass eine XML-Datei unmittelbar editiert wird, möglicherweise noch auf einem Server, dann kommen auch Sicherheitsbedenken zum Vorschein, die gelöst werden müssen. Glücklicherweise gibt es Lösungen, durch die diese Probleme beseitigt werden können.

Mit Hilfe von verschiedenen Bibliotheken ist es möglich, XFORMS in ein HTML umzusetzen, das übliche Browser verstehen. Dabei gibt es im Prinzip zwei Möglichkeiten:

  1. Client-seitige Bibliotheken: Die HTML-Seite mit eingebettetem XForms wird zusammen mit einer Bibliothek an einen Browser ausgeliefert. Diese Bibliothek könnte z.B. in JavaScript geschrieben sein oder es handelt sich um ein XSLT-Template, das XForms in HTML mittels JavaScript transformiert. Die meisten aktuellen Browser erlauben die Client-seitige Transformation von XML-Dokumenten, sie erwarten nur eine passende Processing-Instruction und laden dann bei Bedarf etwa ein XSLT nach. Ein Beispiel für so eine Implementierung ist XSLTForms. Für diese Lösung wird allerdings erwartet, dass man mittels http-put die Datei auf dem Server schreiben kann. Da man direkt auf den Server schreibt, ist dies ein mögliches Sicherheitsproblem, was man z.B. über WebDav ansprechen kann. Für große Anwendungen und diversifizierte Umgebungen mit vielen Benutzern könnte dies problematisch sein. Auch ist die Client-seitige Transformation nicht unbedingt unabhängig vom Browser oder gar vom Gerät. Mit der Zunahme mobiler Anwendungen auf Tablets, etc., könnte dies also ein Grund sein, nach einer anderen Lösung zu suchen. Streng genommen sollte man bei Client-seitiger Verarbeitung auch das gesamte Dokument noch syntaktisch prüfen, bevor man es ablegt - etwas, was XForms zwar erlaubt, aber was bei einer Client-seitigen Verarbeitung von keinem sicherheitsbewusstem Systemverwalter als ausreichend empfunden würde.
  2. Server-seitige Bibliotheken: Die HTML-Seite mit eingebettetem XForms wird von einem Server ausgeliefert, der selbst die Transformation in HTML durchführt. Die Sicherheitsproblematik durch eine syntaktische Überprüfung ist dadurch viel einfacher: Man kann die XForms-Funktionalitäten verwenden, um gegen ein Schema validieren zu können. Gleichzeitig, da nur übliches HTML (mit CSS und JavaScript nach Wunsch) übertragen wird, braucht man keine Browseranpassungen oder Anpassungen an neue Geräte vornehmen. Beispiele für solche Lösungen sind Orbeon oder eben betterFORM. Wir haben uns dabei für betterFORM entschieden, weil es für uns leicht ist, die XForms aus den XML-Dateien zu generieren - das heißt, dass in unserem Anwendungsfall für jedes CMDI-Profil mit seinem passenden XSchema ein geeignetes Formular erstellt werden kann.

XForms mit betterFORM ausliefern

Durch die Generierung der XForms-Strukturen aus den CMDI-Beschreibungen und der Verwendung von CMDI-Instanzen als Datenmodell, sind fast alle Voraussetzungen gegeben, um die Formulare auszuliefern. Wir fügen dazu die XForms-Strukturen in ein XHTML-Dokument ein, so dass wir XHTML-Dateien mit eingebettetem XForms haben. Zur Auslieferung über betterFORM wird daher betterFORM als Webservice in einem Tomcat installiert, die XHTML-Seiten werden in einem spezifiziertem Verzeichnis für den Webservice zugänglich abgelegt. Beim Aufruf der entsprechenden URL wird dann der Tomcat die Datei unter Verwendung von betterFORM ausliefern.

Der Webservice selbst erhält aus Sicherheitsgründen natürlich eine Zugangskontrolle. So kann sichergestellt werden, dass derjenige, der die Bearbeitung vornimmt, dazu auch autorisiert ist, und außerdem kann in den Provenance-Daten für das CMDI-File dieser Name automatisch ergänzt werden.

Die CMDI-Metadaten liegen dabei nur für den Tomcat zugänglich (auch schreibbar für den Tomcat-User) auf dem Server. Das XForm-Formular linkt aber nur darauf, so dass ein großes CMDI-File nicht Teil der XHTML-Datei ist. Dadurch ist auch das Schreiben der Änderungen einfach: die CMDI-Datei, die verlinkt ist, wird einfach überschrieben. Auf Grund der XForms-Syntax-Kontrolle stellt dies kein Sicherheitsproblem dar.

Zusammenfassung

In diesem Artikel haben wir kurz beschrieben, warum und wie wir XForms zur Arbeit mit CMDI-Metadaten einsetzen. In näherer Zukunft werden wir ein Beispielformular an dieser Stelle zeigen, das mit betterFORM erstellt wurde. Und dann können registrierte Nutzer auch selbst Hand an CMDI-Dateien legen. Derzeit wird ein Editor entwickelt, der sich noch in einem geschlossenen Alpha-Test befindet. Noch....