Jusletter IT

Wer juristische Fachinformationen sammelt oder anbietet, tut gut daran, diese in einem zukunftssicheren Datenformat einheitlich und möglichst «plattformunabhängig und medienneutral» zu speichern. Vor zwanzig Jahren lautete eine häufige Empfehlung dafür «SGML». Als sich um die Jahrtausendwende XML durchsetzte, gab es nur wenig Konvertierbedarf, weil XML in den meisten Belangen eine Teilmenge von SGML darstellt. Es wurden XML-fähige Datenbanken und Internet-Anwendungen entwickelt, sodass man mit den gespeicherten Daten direkt arbeiten konnte, ohne sie vorher zu transformieren. Meist werden die Datenbankinhalte unmittelbar in der Anwendung des Nutzers zu HTML-formatiertem Text browserfähig aufbereitet.

Inzwischen hat sich ein sehr breiter Markt mit Anwendungen für mobile internetfähige Endgeräte entwickelt und innerhalb dieser mobilen Apps haben sich mainstream-Technologien herausgebildet. Da auch die juristischen Nutzer gerne und erfolgreich mit Smartphones, Tablet-PCs und digitalen persönlichen Assistenten arbeiten, stehen die Verbreiter von Fachinformationen vor der Frage, welche Neuerungen diese Entwicklung von ihren Datenbanken verlangt. Können die XML-Inhalte vorhandener SQL-fähiger Datenbanken für Apps auf diesen Endgeräten genutzt werden?

Eine einfache Herangehensweise wäre es, die an die neueren Endgeräte angepassten eigentlichen Apps zu ignorieren und darauf zu bauen, dass der Nutzer mit einer Web-Adresse in seinem Browser eine Internetanwendung auf einem Server des Anbieters nutzt. Dann gibt es zwar keine Grundprobleme mit dem Datenformat. Aber erstens muss der Nutzer dazu dauerhaft online sein, zweitens wird die Funktion des Programms abhängig von der Verbindungsqualität und Netzgeschwindigkeit. Und drittens hat sich sowohl das Nutzerverhalten als auch die Politik der Betriebssystemabschottung durch die Hersteller an die neuen Geräte angepasst.

Der Nutzer erwartet kleine schlanke Applikationen, die nach einmaligem Laden auch ohne ständige online-Verbindung funktionieren. Und es gibt herstellerseitige Voraussetzungen für die Akzeptanz von Apps auf ihren Betriebssystemen. Beispielsweise kann man für ganze Gerätegruppen als App-Anbieter nur sinnvoll Kunden ansprechen, wenn diese in einem online-App-Store des Geräteherstellers mit Zertifizierung hinsichtlich der Betriebssystemkompatibilität verfügbar sind. Und zudem ist zu beachten, dass die Ersteller von sogenannten Apps eine eigene Gruppe von Spezialisten sind, deren Leistungen man z.B. als Informationsvermittler oft günstiger einkaufen kann, als dass man die erforderlichen Kenntnisse in-house vorhält. Das bedeutet, dass die Daten an solche App-Entwickler gehen und erst danach wieder als HTML oder Ähnliches auf einem Smartphone landen.

Für die erforderlichen Zwischenstufen wurden NoSQL-Datenbanken entwickelt. Das Akronym steht für Not-only-SQL und bedeutet z.B., dass diese Datenbanken sich - im Unterschied zu relationalen Datenbanken - flexibel an die vorgefundenen Strukturen der Datenbankinhalte anpassen können, dass die Datensätze verteilt, sogar im Internet verteilt, vorliegen können und dass neue Informationen auch ohne vorherige Indexierung sofort überall zur Verfügung stehen. Hinzu kommt der große Vorteil, dass z.B. die Datenbanken MongoDB und CouchDB gleichzeitig Webserver sind und dass somit die komplette Funktionsbreite für Recherchen, Input und Output über http-Schnittstellen zur Verfügung steht. Außerdem werden diese Datenbanken mit einer sehr großen Datenmenge fertig, auch Facebook, Twitter und Amazon nutzen nicht-relationale Datenbanksysteme.¹

Manchmal werden solche Datenbanken nicht als «database» bezeichnet, sondern «nur» als «key-value-stores» (Schlüssel-Wert-Speicher). Ein gutes Anschauungsmaterial ist z.B. auch die registry von Windows-Rechnern. Aber was ist nun die Hürde, die es zu überspringen gilt, bevor man als Informationsanbieter über so eine Datenbank und eine Ajax-App oder eine Javascript-Anwendung auf das Smartphone oder Tablet seines Nutzers kommt? Die flexibel und einfach weiterbenutzbaren Datenbankanwendungen erfordern jedenfalls ab einer bestimmten Funktionalitätsstufe anstelle des früher üblichen XML einen Input in Form von JSON-Dateien.

JSON (Javascript Object Notation) ist eine sehr holzschnittartig definierte Datenhaltungssprache. Sie gehorcht folgenden formalen Regeln:

 

Es gibt Schlüssel und Werte.

 

Schlüssel entsprechen dabei den «Feldbezeichnern», den «Spaltenköpfen» in relationalen Tabellenstrukturen und den Elementnamen in der SGML/XML-Welt. Die Werte sind die Inhalte. Beides steht in Anführungszeichen und ist durch einen Doppelpunkt getrennt. Schlüssel-Wert-Paare, die durch geschweifte Klammern umschlossen sind, nennt man Objekt. Objekte können hintereinander angeordnet sein, dann stehen Kommata dazwischen. Objekte können auch gleichgeordnet, also bildlich «nebeneinander» stehen, dann nennt man diese Anordnung «Array». Dabei sind die Objekte ebenfalls durch Kommata getrennt, aber der gesamte Array ist noch durch eckige Klammern umschlossen. Als Zeichen stehen nur die ANSI-Zeichen der Computertastatur zur Verfügung, alle Sonderzeichen sind in UTF-8 zu umschreiben. Da es keine weiteren Regeln für JSON gibt, eignet sich dieses Datenformat gut für den Datenaustausch und für die medienneutrale Datenhaltung. Seine Grammatik wird z.B. auf der Homepage http://json.org/json-de.html in fünf schematischen Abbildungen verständlich dargestellt.

Der einzige Nachteil für Anbieter, die schon bisher Datensammlungen haben, ist, dass die Daten nun umgeformt - oder neu erfasst - werden müssen, damit die - bereits nicht mehr ganz neue - neue Welt sie akzeptiert. Dabei hängt es von der Konvertersituation ab, ob die Daten zu verdoppeln sind oder ob sie im Zuge einer Exportroutine direkt und automatisch von XML zu JSON umgewandelt werden können. Ziel ist letzteres.

Es existieren inzwischen viele XML-zu-JSON-Konvertierer, manche sogar browserbasiert. Da fragt man sich schon, wozu man einen eigenen schreiben sollte. Allerdings war die Situation Anfang 2011 noch anders und außerdem sollte man die Angebote online erst einmal ausprobieren.

6.1 Als erstes gegoogeltes Beispiel herausgegriffen sei: http://www.thomasfrank.se/xml_to_json.html

Testablauf: Eine beliebige Sammlung von Adressen in wohlgeformtem XML mit einigen ISO-Sonderzeichen wurde mit der Anwendung online zu JSON konvertiert. Anschließend wurde das Ergebnis bei http://jsonlint.org/ zur Validierung einkopiert. Leider ergab sich bereits in Zeile 1 eine Fehlermeldung «Expecting a string». Offenbar vermisst der Parser im Ergebnis eine Reihe von Anführungszeichen. Die Bearbeitung erfolgte rasch, das Script scheint aber leider offenbar nicht für alle Konventionen gerüstet.

6.2 Vielversprechend war auch: http://www.freeformatter.com/xml-to-json-converter.html.

Hier erfolgt derselbe Test, aber leider erscheint statt des Outputs nur die Meldung "Unable to format the JSON output. The entity "uuml" was referenced, but not declared." Das Programm ist leider beim ersten "ü", welches als ü codiert war, ausgestiegen. Für einem zweiten Test wurden daher vorab alle "&" zu # verwandelt. Die Umwandlung verläuft nun problemlos, das Ergebnis sieht gut aus, aber leider meldet der JSONLint-Parser 2 einen Fehler, allerdings ohne die Fehlerposition anzugeben: " JSON.parse: expected property name or '}'".

6.3 Als drittes wurde folgende Adresse getestet: http://www.utilities-online.info/xmltojson/#.UNxh0ndsl6Y

Hier erfolgt derselbe Test, aber leider erscheint auch hier statt des Outputs nur die Meldung "parsererror": { "#text": "XML-Verarbeitungsfehler: Nicht definierte Entität, Adresse: http://www.utilities-online.info/xmltojson/#.UNxh0ndsl6Y Zeile Nr. 1, Spalte 147:" Auch dieses Programm ist beim ersten "ü", welches als ü codiert war, ausgestiegen. Für einen zweiten Test wurden daher vorab alle "&" zu # verwandelt. Die Umwandlung verläuft nun problemlos und auch der JSONLint-Parser als Benchmark wird fehlerfrei passiert.

Eines der Hauptprobleme scheint der Umgang mit Sonderzeichen zu sein. Hier gibt es mehrere JSON-«Dialekte» und in dieser Frage verhalten sich auch die als Zielumgebung angestrebten NOSQL-Datenbanken manchmal etwas wählerisch. Zum Beweis genügt eine Google-Recherche mit dem Suchbegriff «json utf-8 couchdb». Problemlos geht es nur weiter, wenn alle Umlaute in den JSON-Dateien mit UTF-8-Codierungen im \uNNNN-Format abgespeichert sind und alle Textstrings mit doppelten Anführungszeichen umhüllt werden.

Demgemäß geht der hier vorgestellte - spezifisch für deutsche Vorschriften gedachte - PERL-Konverter wie folgt an die Sache heran:

8.1 Ein Eingangs- und Ausgangsverzeichnis werden festgelegt, sodass die Ursprungsdateien unangetastet bleiben. Für Fehlersuchen werden mehrere Scripte hintereinandergeschaltet und Zwischen-Output-Verzeichnisse angelegt. Die XML-Dateien kommen ins Eingangsverzeichnis und ihre Dateinamen werden als Liste gespeichert. Diese Liste arbeitet der Konverter ab.

8.2 Zuerst werden die in vielen XML-Dateien üblichen Kommentare am Dateikopf und die Doctype-Zeile sowie eventuelle Stylesheet-Aufrufe gelöscht. So bleibt als erster Eintrag in der Datei das XML-Starttag des Root-Elements übrig.

8.3 Falls eine DTD existiert, die XML-Dateien also nicht nur well-formed, sondern auch parserfähig valide sind, kann die DTD auf Elemente und Attribute durchgesehen werden, die in der Zielumgebung überflüssig sind. Dann werden im Konverter gleich zu Beginn die entsprechenden Starttags und Endetags sowie Attribute mit zugehörigen Werten gelöscht. Im konkreten Beispiel werden nicht benötigte Starttags mit regulären Ausdrücken wie "\]*\>" angesprochen und durch "" ersetzt. Dabei bedeutet [^\>]*\> "eine beliebig lange Reihe beliebiger Zeichen bis auf das 'größer als'-Symbol, und zwar solange, bis das 'größer als' das erste Mal auftritt", ein mächtiger und manchmal auch überraschender Suchbegriff. Der Ersetzungsterm "" hingegen bedeutet «nichts».

8.4 Leere XML-Elemente liegen meist in der Notation "" vor. Zur Vereinheitlichung und zum einfacheren Weiterarbeiten, werden diese vorab mit Endetags versehen, also umgeformt zu "".

8.5 In JSON werden geschweifte und eckige Klammern zur Strukturierung verwendet, in XML dürfen sie hingegen als gewöhnliche Schriftzeichen interpretiert werden. Daher müssen vor einer Konvertierung von XML zu JSON geschweifte und eckige Klammern "escaped" werden, also durch eine explizite Sonderzeichennotation ersetzt. Wenn nun im Laufe der weiteren Konvertierschritte XML-Tagging in Zeichen wie {, }, [ oder ] verwandelt wird, kann es nicht mehr zu einer Verletzung der notwendigen Spiegelbildlichkeit solcher Sonderzeichen kommen.

8.6 In XML werden Spitzklammern, also < und > zur Strukturierung verwendet. Zur Sicherheit vor künftigen Verwechslungen dürfen daher die Escape-Sequenzen < und > ('kleiner als' und 'größer als'-Zeichen) nicht in Klartext umgesetzt werden. Sie sind vorab umzuformen zu den UTF-8-Sequenzen \u003E; und \u003C;.

8.7 Anführungszeichen um Attributwerte herum werden anders behandelt als solche im fließenden Text. Das bedeutet, dass zuerst nur die Inhalte von XML-Starttags bearbeitet werden dürfen, danach erst der Rest der Datei. Da Starttags mit regulären Ausdrücken gefunden werden können, ist dies gut lösbar. Zu empfehlen ist es, vorweg alle vorhandenen Zeilenendezeichen (Carriage return / Line feed) zu löschen und dann vor jede öffnende XML-Spitzklammer ein Zeilenendezeichen einzufügen. Bereits als XML-Sonderzeichen vorliegende Anführungszeichen wie „ " und so weiter kann man durch die UTF-Sequenz \u0022 ersetzen. Ab dann werden Anführungszeichen, die man später im JSON-Format behalten möchte, zuerst einmal als ¶quot; geschrieben und erst am Ende wird dieser Platzhalter dann durch «echte» Anführungszeichen ersetzt.

8.8 PCDATA -Elemente werden zu einer JSON-Konstruktion wie {"c":"PCDATA"} gemacht, weil «frei schwebender» Text zwar in juristischen Textsorten häufig ist, in JSON aber nicht geduldet wird. Das «c» steht für «content», ist aber frei gegriffen.

8.9 Attribute aus Starttags werden nun zu eingeschachtelten Objekten. Das heißt, zuerst einmal stellt sei der Konverter strukturell korrekt zu eingeschachtelten XML-Sub-Elementen um. Diese werden später (siehe 11) dann vom generischen Elemente-Verwandlungs-Befehl mit erfasst.

8.10 Nun werden alle erdenklichen Sonderzeichen zu UTF-8 umgebaut, das sind im Anwendungsbeispiel ca. 1000 Zeilen Suche-Ersetze-Code in der Form "      s !\ü\;!\\u00FC!go;       ". Es empfiehlt sich hierbei, alle Zeichen oberhalb ANSI-0127 sowie alle greifbaren ISO-Alphabete abzudecken. Denn mit dem Einzug des EU-Rechts in Anhänge und Anlagen des nationalen Rechts haben in juristischen Texten viele kyrillische, griechische, isländische, nordische und slawische diakritische und Sonderzeichen eine Bleibe gefunden. Am Ende kann es nützlich sein, nochmals zu überprüfen, ob noch ein Treffer mit der Suche nach dem regulären Ausdruck "[€-ÿ]" erzielt wird. Denn wie bereits erwähnt: die Massenimport-Schnittstellen der NoSQL-Datenbanken sind an dieser Stelle empfindlich und die Fehlermeldungen nicht sehr aussagekräftig.

8.11 An dieser Stelle enden die Vorbereitungshandlungen und die verbliebenen und vereinheitlichten Start-Tags werden wie folgt umgewandelt:

8.11.1 XML-Elementnamen werden nach einer öffnenden geschweiften Klammer und vor einen Doppelpunkt in Anführungszeichen gesetzt.

8.11.2 Hinter den Doppelpunkt kommt eine öffnende eckige Klammer.

8.11.3 Ergeben sich dabei - als Folge der Attribut-zu-Element-Umformung - hypertrophe Konstrukte mit leerem Textinhalt, werden diese sogleich durch eine Suche nach direkt aufeinander folgenden öffnenden und schließenden Klammerpaaren wieder beseitigt.

8.11.4 An dieser Stelle des Konverter-Designs ist erneut ein Blick in die XML-DTD nützlich. Es sollte eine Liste mit den Namen der blockbildenden Strukturelemente geschrieben werden, die selbst nur Subelemente, aber keinen unmittelbaren #PCDATA-Content haben. . Im konkreten Anwendungsfall für deutsche Vorschriften z.B. , ,

8.12 Ende-Tags von blockbildenden Elementen werden dann gezielt ersetzt durch eine schließende eckige und eine schließende geschweifte Klammer. Alle verbliebenen Endetags werden nun ersetzt durch eine schließende eckige und eine schließende geschweifte Klammer und ein nachfolgendes Komma. Überflüssige Kommata beseitigt dann ein Befehl, der Kommata unmittelbar vor schließenden eckigen Klammern löscht.

8.13 Nun können noch die oben escapeten Sonderzeichen zurückverwandelt werden. Übrig sollte valides JSON bleiben. Die Zieldateien erhalten die Endung *.JSON können über eine RESTful-API z.B. mit curl in CouchDB importiert werden

Der Konverter muss erstmalige Datenumformungen anders behandeln als Updates. Die NoSQL-Datenbasis CouchDB beispielsweise arbeitet mit absoluter Kontrolle der Objektintegrität. Zwar gibt es viele Wege für neuen raschen Input. Aber falls sich die Datenbank nicht sicher ist, dass ein Input ein Update eines bereits vorhandenen Objektes ist, behandelt sie jedes neu aufgenommene Objekt als komplett neues Objekt. Diese Vorsichtsmaßnahme im Datenbankdesign birgt im juristischen Umfeld folgendes Problem: Wenn sich z.B. eine gesetzliche Vorschrift ändert, dann würde der Nutzer das nicht mitbekommen, sondern die Änderung als zusammenhanglose Neuheit betrachten, anstatt sie in einer Reihe mit den Vorgängerregelungen zu sehen. Daher muss der Konverter bei Aktualisierungen vorhandener Objekte den datenbankinternen Schlüssel der Vorgängerversion ermitteln und diesen der Nachfolgerversion sozusagen als Passwort mitgeben, damit auch CouchDB den neuen Input als Update eines bereits vorhandenen Objektes behandelt.

Eine Sammelabfrage ermittelt die (logisch benannte, eineindeutige) _id und die datenbankintern gespeicherte zugehörige revisions-id ("_rev") aller zu aktualisierenden Objekte und schreibt sie in eine Liste. Die zu aktualisierenden konvertierten JSON-Objekte werden geöffnet. Entsprechend der soeben ermittelten Liste werden vom Konverter vorbereitete Platzhalter für "_rev" durch die aktuell ermittelte Revisionsnummer aus CouchDB ersetzt. Das Ergebnis kann dann mit Erfolg als neue Version des Vorgängerobjektes importiert werden.

Der Konverter im Anwendungsbeispiel ist mit PERL in einer Windows-Umgebung realisiert. Die Input-Scripte schließen sich direkt an. Sie benötigen die curl-Umgebung² setzen im Ausgabe-Verzeichnis von PERL an, und sind gewöhnliche Batch-Dateien. Der Konverter ist zwar spezifisch für deutsche Vorschriftentexte entwickelt. Aber die strukturellen Ideen zum Aufbau und die Abfolge der Konvertierschritte sowie die Behandlung der Sonderzeichen sollten soweit generisch sein, dass auch andere Umwandlungswerkzeuge nach dem hier vorgestellten Ablaufplan erstellt werden können.

 

---

 

Alexander Konzelmann, Abteilungsleiter, Richard Boorberg Verlag GmbH & Co KG, Boorberg Rechtsdatenbanken RDB.

 

---