Jusletter IT

In wenigen wissenschaftlichen Disziplinen ist die Ausarbeitung systematischer¹ Texte von solcher Bedeutung, wie in der Informatik und der Rechtswissenschaft² . Systematische Texte sind in der Informatik vor allem als Quelltexte sowie technische Richtlinien von Bedeutung und in der Rechtswissenschaft als individuelle Normen, wie etwa Verträge und generelle Normen, wie etwa Richtlinien, Gesetze oder Verordnungen. All diesen Textarten ist gemein, dass

• sie – in der Regel – einem strengen systematischen Aufbau folgen,
  
• ihre Qualität wesentlich von der Qualität ihrer Systematik abhängt und
  
• sie unmittelbare³ Auswirkungen haben.

Die Ausarbeitung der genannten systematischen Texte selbst unterliegt unterschiedlich strengen Regeln. Im juristischen Bereich bestehen auf der einen Seite beispielsweise einheitliche und sehr detaillierte Regeln über die Ausarbeitung von Gesetzesentwürfen («Legistik»)⁴ auf der anderen Seite keine verbindlichen Regeln für die Ausarbeitung von Vertragstexten⁵ . Auch hinsichtlich der technischen Richtlinien gibt es unterschiedlich strenge Vorgaben für die Erstellung systematischer Texte⁶ . Auf Grund der schnellen Entwicklung – insbesondere der IT – sind allerdings streng determinierte und damit schwerfälligere Instrumente nicht immer die Mittel der Wahl.

Darüber hinaus gibt es allgemeine Regelwerke über das Verfassen wissenschaftlicher Texte, wie etwa für den juristischen Bereich die – auch diesem Beitrag zu Grunde liegenden – Abkürzungs- und Zitierregeln der österreichischen Rechtssprache und europarechtlicher Quellen (AZR)⁷ oder das Blue Book⁸ .

Es bestehen gute Gründe sich aus Sicht der Rechtsinformatik mit den Regeln für die Erstellung systematischer Texte auseinanderzusetzen, denn der Aufwand zur Einhaltung steigt auf Grund

• der einzuhaltenden Regeln mit deren
  
• Anzahl und
  
• Abstraktionsgrad⁹ ,
  
• des auszuarbeitenden Textes mit dessen
  
• Komplexität und
  
• Umfang und
  
• der Art des Projektes mit
  
• der Anzahl der zu verwaltenden Versionen (Projektdauer) sowie
  
• der Anzahl der beteiligten Personen.

Dies ist freilich keine neue Erkenntnis, macht aber deutlich warum beispielsweise die softwaremäßige Unterstützung bei der Ausarbeitung von Rechtstexten besonders im legistischen Bereich weit verbreitet ist. Hier ist das Potential für die Steigerung der Effizienz bei der Ausarbeitung systematischer Text besonders groß, weil eine Vielzahl von Regelungen für die Ausarbeitung besteht. Nichtsdestotrotz können sich auch beachtliche Einsparungspotentiale in noch weniger streng reglementierten Bereichen – wie etwa der Vertragsgestaltung – ergeben, da nicht erst mühevoll Systematiken entwickelt werden müssen.

Bereits ein oberflächlicher Blick in die für Legisten relevanten (Form)vorschriften zeigt, dass äußerst exaktes Arbeiten gefordert wird. Es kommt im wahrsten Sinne des Wortes auf Punkt und Beistrich an. Kernstück dieser (Form)vorschriften¹⁰ bilden die Legistischen Richtlinien 1990 (LRL). Sie setzen sich mit der Rechtssprache (Kapitel I LRL), der Rechtstechnik (Kapitel II LRL) und der formellen Gestaltung (Kapitel III LRL) auseinander. In der Folge sollen aus jedem Kapitel ausgewählte Richtlinien sowie die Möglichkeiten ihrer softwaremäßigen Implementierung diskutiert werden, wobei sich zeigt, dass vor allem die sehr allgemeinen Regeln zur Rechtssprache und Rechtstechnik – momentan noch – kaum umsetzbar sind.

Einige Regeln des KapitelsRechtssprache wie etwa zur sprachlichen Sparsamkeit (LRL 1), zu Wiederholungen (LRL 4) oder zur sprachlichen Klarheit (LRL 7) können durchaus auch als Regeln für die Erstellung von Vertragstexten herangezogen werden und beschränken sich nicht auf die Ausarbeitung legistischer Texte. Die Regeln zur Rechtssprache behandeln Allgemeines (LRL 1 bis 10), Textaufbau (LRL 11 und 12), Paragrafenaufbau (LRL 13 und 14), Satzbau (LRL 15 bis 26) sowie Ausdruck (LRL 27 bis 36). Sie können nur sehr schwer softwaremäßig umgesetzt werden, da sie einerseits exzellente Sprachkenntnis erfordern – vgl. LRL 1, wonach «Rechtsvorschriften [...] knapp und einfach zu fassen » sind – oder andererseits vom eigenen Standpunkt abhängen – vgl. wiederum LRL 1, wonach «jedes überflüssige Wort [...] zu vermeiden » ist. Möglich erscheint etwa die Umsetzung oder zumindest annähernde Umsetzung von

• LRL 4, die die Wiederholung von Gesetzestext in Verordnungen verbietet, durch Berechnung der Ähnlichkeit von Rechtstexten,
  
• LRL 5, die verbietet, den Geltungsbereich einer Norm durch einen allgemeinen Vorbehalt gegenüber einer anderen Rechtsvorschrift zu regeln, durch Suche dafür typischer Formulierungen,
  
• LRL 6, die Beispiele in Gesetzestexten verbietet, auch durch Suche bestimmter Signalwörter wie «zum Beispiel » oder «beispielsweise »,
  
• LRL 13, die die Länge von Paragrafen regelt, durch Zählen der Wörter und Absätze,
  
• LRL 15 bis 18, die vor allem kurze, einfache Sätze vorsehen, durch Zählen der Wörter und Formulierungen, die für Nebensätze typisch sind oder
  
• LRL 28, die Hauptwortphrasen verbietet, durch Suche typischer Hauptwortphrasen, wie etwa «Verwendung finden » oder «Geltung besitzen ».

Momentan kaum zu realisieren, aber sehr interessant wäre eine Umsetzung von LRL 31, wonach – am Besten für die gesamte Rechtsordnung – eine einheitliche Begrifflichkeit zu verwenden ist. So ist in einigen Bundesnormen¹¹ von «pseudonymisierten Daten» die Rede, obwohl es eigentlich den datenschutzrechtlichen Begriff der «indirekt personenbezogenen Daten» (§ 4 Z 3 Datenschutzgesetz 2000 [DSG 2000] BGBl. I Nr. 165/1999) gibt. Ist die Einheit von Gegenstand und Begriff durch die Verwendung mehrerer Begriffe für denselben Gegenstand gestört, werden schwierige und zugleich vermeidbare Auslegungsprobleme aufgeworfen. Dass – trotz unterschiedlicher Begriffe – doch derselbe Gegenstand gemeint ist, erfordert oft Fachwissen oder umfangreiche Recherchen. Der Zugang zum Recht wird dadurch unnötigerweise erschwert.

Auch das KapitelRechtstechnik mit seinen Unterkapiteln zeitlicher Geltungsbereich (LRL 37 – 53), Verweisungen (LRL 54 – 64), Novellen (LRL 65 – 78), Vollziehung (LRL 79 – 83), Ermessen (LRL 84 und 85), Legalitätsprinzip (LRL 86 – 89), Grundsatzgesetze (LRL 90 – 92) und Sonstiges (LRL 93 – 99) setzt juristische Kenntnisse voraus, die kaum oder gar nicht in Software umgesetzt werden können. Möglichkeiten zur Umsetzung bestehen für

• die LRL zum zeitlichen Geltungsbereich, nur insofern, als bei Novellen automatisch Inkraft- und Außerkrafttretensbestimmungen erzeugt werden könnten,
  
• LRL 44, die materielle Derogationen¹² verbietet, durch Suche bestimmter Formulierungen wie «alle* » und «außer Kraft » in einem Satz,
  
• LRL 46, wonach der Zeitpunkt der Aufhebung ausdrücklich angeführt werden soll, durch Suche bestimmter Formulierungen wie «wird aufgehoben. ».
  
• LRL 48 über die verfassungskonforme Rückwirkung, durch Hinweis auf die verfassungsrechtlichen Voraussetzungen, wenn ein Inkrafttretensdatum in der Vergangenheit liegt,
  
• LRL 50 über die Aufhebung von Derogationsvorschriften, durch Hinweis auf deren Wirkungslosigkeit¹³ ,
  
• LRL 51, wonach Verfassungsbestimmungen nur durch andere Verfassungsbestimmungen in Kraft oder außer Kraft gesetzt werden dürfen, durch Überprüfung des Wortes «Verfassungsbestimmung » vor beiden Bestimmungen,
  
• LRL 59 über die Klarheit der Verweisung, durch Suche bestimmter Formulierungen wie «sinngemäß » und «angewendet » oder «anzuwenden »,
  
• LRL 63 über verfassungswidrige dynamische Verweisungen auf Rechtsvorschriften eines anderen Normgebers, durch Überprüfung der Rechtsform der verweisenden und der verwiesenen Bestimmung oder
  
• LRL 79 über die Regelung des Vollziehungsbereichs, durch Überprüfung ob erstens eine Vollziehungsklausel überhaupt vorgesehen ist und zweitens alle Bestimmungen der Novelle/des Gesetzes darin angeführt sind.

Gut umgesetzt werden kann hingegen das Kapitel über dieformelle Gestaltung , das aus den Unterkapiteln Titel (LRL 100 – 105), Promulgationsklausel¹⁴ (LRL 106 – 110), Gliederung der Rechtsvorschrift (LRL 111 – 119), Novellen (LRL 120 – 130), Zitierregeln (LRL 131 – 138), Schreibweise von Zahlen (LRL 139 – 143), Zeichensetzung (LRL 144 – 147) sowie Abkürzungen (LRL 148 und 149) besteht.

Die Nachvollziehbarkeit, Klarheit und einfache Erweiterbarkeit ist im Bereich der Informatik ein bedeutendes Eigeninteresse desjenigen, der den systematischen Text (Quelltext) ausarbeitet. In der Rechtswissenschaft ist das hingegen nicht immer Ziel, weil zum Beispiel politisch heikle Gesetzesentwürfe oder wichtige Vertragsbestimmungen, die schwer nachvollziehbar sind, die eigene Position – zumindest kurzfristig – stärken können. Außerdem fallen im juristischen Bereich die Rollen der für die Ausarbeitung verantwortlichen Personen und der betroffenen Personen auseinander, sodass im juristischen Bereich größtenteils kein Eigeninteresse an einem nachvollziehbaren, klaren und einfach erweiterbaren Text besteht. Ganz anders ist die Interessenlage in der Informatik. Hier ist die Einhaltung von (Form)vorschriften organisatorische Voraussetzung um möglichst fehlerfreie Software, in Teams und über einen längeren Zeitraum erstellen zu können. Es gibt keine verbindlichen Richtlinien¹⁵ sondern verschiedene Schulen und Denkansätze wie objektorientiertes Programmieren oder den von Smalltalk¹⁶ übernommenen Modell-View-Controller-Ansatz¹⁷ , die v.a. auf leichte Handhabbarkeit und damit Weiterverwendbarkeit von Quelltext setzen. Unterstützt werden diese Ansätze durch Entwicklungsumgebungen (Integrated Development Environments, IDEs) und – im professionelleren Bereich – durch Software Configuration Management (SCM) Systeme, deren Aufgaben vorrangig in der Unterstützung der Softwareentwicklung sowie des Entwicklungsprozesses per se liegen¹⁸ . Davon umfasst sind:

1. die Verwaltung des Quelltextes, um Änderungen an der richtigen Stelle vorzunehmen,
   
2. die Verwaltung der Entwicklungswerkzeuge, um für die jeweilige Version, die richtigen Entwicklungswerkzeuge einzusetzen,
   
3. ein Berichtswesen, um nachvollziehen können, welche Änderungen von wem wie vorgenommen worden sind,
   
4. ein Validierungsprozess, der die Qualität der erzeugten Software sicherstellt,
   
5. so genanntes Build¹⁹ Management, um den build-Vorgang zu vereinfachen,
   
6. Prozessmanagement, um koordinierte und dadurch effiziente Softwareerstellung zu ermöglichen sowie
   
7. Teamwork, um die Zusammenarbeit unter den Entwicklern zu forcieren und Änderungen zeitnahe in das System zu übernehmen.²⁰

Eines der größten Probleme bei der Ausarbeitung systematischer Texte ist der Verlust der Übersicht. Um auch bei umfangreichen und komplexen Projekten – in Informatik oder Rechtswissenschaft – nicht die Übersicht zu verlieren, bedarf es guter Organisation. Diese wird in der Informatik durch die bereits erwähnten SCM-Systeme forciert, für die es in der Rechtswissenschaft bis dato noch keine Pendants gibt.

Aus dem obigen Anforderungsprofil an SCM-Systeme lassen sich bereits auf den ersten Blick zwei Anforderungen ohne weiteres streichen und zwar Punkt 2, die Verwaltung der Entwicklungswerkzeuge sowie Punkt 5, das Build Management. Beide Punkte sind ausschließlich für die Softwareentwicklung relevant und sind daher hier nicht von Interesse. An Stelle der Entwicklungswerkzeuge (Punkt 2) müssten jedoch spezielle juristische Werkzeuge verwendet werden. In Ansätzen gibt es schon heute solche Werkzeuge, wie etwa die Legistikmakros im eRecht²¹ , die allerdings noch einen recht bescheidenen Funktionsumfang haben. Interessant wären inhaltliche Funktionen, wie etwa die automatische Anpassung von Verweisungen, das Erkennen von Gliederungsfehlern oder eine strenge Benutzerführung²² , die regelwidriges Arbeiten – wie etwa die unsystematische Benennung von Versionen – nicht zulassen oder dadurch ausschließen, dass sie diese Arbeit für den Benutzer übernehmen.

Der in Punkt 4 genannte Validierungsprozess ist in der Legistik das Begutachtungsverfahren und im anwaltschaftlichen Bereich, die Einladung zur Stellungnahme. Auch hier gibt es große Rationalisierungspotentiale, wenn man nur bedenkt wie unsystematisch diese Prozesse oft durchgeführt werden und beispielsweise Zusammenfassungen von Begutachtungsverfahren noch immer nicht datenbankbasiert, sondern im Wege – manueller – Textverarbeitung durchgeführt werden.

Die Anpassung bestehender Software Configuration Management Systeme an die juristischen Bedürfnisse ist auf Grund der unterschiedlichen Anforderungen nicht zielführend. Weder können Entwicklungsumgebungen²³ , die auf Programmiersprachen abstellen, eingesetzt werden, noch sind Buildwerkzeuge erforderlich. Auch Validierungs- und Berichtwerkzeuge, die typischerweise Bestandteil eines Software Configuration Management Systems sind, müssten speziell für jursitische Bedürfnisse angepasst werden. Legt man die Anforderungen gemäß Kap. 1.4 auf ein «Legal Configuration Management System» um, so müsste ein solches aus:

1. einem Versionskontrollsystem,
   
2. einem juristischen Editor,
   
3. einem juristischen Validierungswerkzeug und
   
4. einem juristischen Berichtwerkzeug

bestehen.

Zur Integration in bestehende Systeme wäre es vorteilhaft einen Export für gängige Dateiformate zu haben. Auch empfiehlt sich die Implementierung als Webapplikation, da damit eine Installation auf den Geräten der Applikationsanwender nicht mehr notwendig ist und zudem von überall gearbeitet werden kann. Selbstverständlich sind dabei Sicherheitsvorkehrungen durch Verschlüsselung, Passwortschutz und sicherheitsbewusste Programmierung²⁴ zu treffen.

Kernstück eines «Legal Configuration Management» Systems müsste ein Versionskontrollsystem sein, das sowohl die eigentlichen Nutzdaten, als auch die Änderungen an diesen sowie die zugehörigen Kommentare verwaltet. Heutzutage gibt es bereits eine große Zahl solcher Tools, die ihren Ursprung im Softwareenineering und dort insbesondere in der Verwaltung von Quelltext haben. Da diese Systeme oftmals bereits jahrelang im Einsatz und dementsprechend erprobt sind, ist die Neuentwicklung eines Versionskontrollsystems nicht zielführend. Angeboten werden sowohl proprietäre als auch quelloffene Systeme in unterschiedlichen Ausprägungen. Die Anforderungen, die sich typischerweise aus einem Einsatz im juristischen Bereich ergeben, erfüllen aber nicht alle, weshalb eine nähere Untersuchung der wesentlichen Eigenschaften von Versionskontrollsystemen lohnt.

Eine der wichtigsten Entscheidungen ist die Wahl zwischen zentraler und verteilter Speicherung. Die Stärken zentraler Systeme²⁵ bestehen in der Synchronisierung, Nachverfolgung und Sicherung der Daten²⁶ , während verteilte Systeme²⁷ unabhängig von einer Netzwerkverbindung sind und ihr Hauptaugenmerk auf der Verteilung von Änderungen liegt.

Im juristischen Bereich muss oft nur für das Verwalten des «Master-Documents» allein schon ein großer Aufwand betrieben werden. Meistens wird dafür eine verantwortliche Person bestimmt, die das «Master-Document» auf aktuellem Stand zu halten hat und für die Einarbeitung allfälliger Änderungen verantwortlich ist. Das bedeutet nicht nur einen hohen Aufwand für diese Person, sondern bringt auch Probleme, wenn sie beispielsweise krankheitsbedingt ausfällt. Derartige Probleme könnte man mit einer zentralen Speicherung – es gibt dann nur eine «authentische» Version – vermeiden.

Eng verbunden mit der grundsätzlichen Struktur – zentral oder verteilt – ist die Frage des Konfliktmanagements: wie werden konkurrierende Änderungen an denselben Daten behandelt? Auch hier gibt es im Wesentlichen zwei Lösungsansätze und zwar das Zusammenführen von Änderungen («merge») und den exklusiven Zugriff («lock»). Der Nachteil des Merge-Modells besteht darin, dass Änderungen oft nicht automatisiert zusammengeführt werden können, da es bei einander widersprechenden Änderungen einer fachkundigen Entscheidung bedarf, welche Änderungen übernommen werden sollen und welche nicht. Dafür sind aber auch parallele Änderungen möglich, d.h. die Personen, die an dem Text arbeiten blockieren einander nicht, sondern können zur selben Zeit am selben Dokument arbeiten. Damit kommen wir gleich zum Nachteil des Lock-Modells. Hier kann jeweils nur eine Person an einem bestimmten Dokument Änderungen vornehmen. Es kann also speziell bei großen Teams zu einem gegenseitigen Blockieren kommen, insbesondere, wenn es Dokumente gibt, die oft geändert werden müssen. Demgegenüber steht der Vorteil, dass es keiner Regeln bedarf welche Änderungen übernommen werden und welche nicht, weshalb die bearbeiteten Dokumente auch vom Versionskontrollsystem selbst konsistent gehalten werden können.

Grundsätzlich ist für den juristischen, insbesondere legistischen Bereich das Lock-Modell zu bevorzugen, da zu jeder Zeit eine konsistente Version, d.h. eine Letztfassung, des bearbeiteten Textes verfügbar ist. Dem Problem des gegenseitigen Blockierens könnte durch eine geschickte Aufteilung des Dokumentes in mehrere kleine Dateien entgegengewirkt werden. Auch gibt es Produkte²⁸ , die sowohl Merging als auch Locking unterstützen.

Unter Tagging versteht man die Eigenschaft bestimmte Versionen mit einer Bezeichnung zu versehen. Das ist insbesondere im juristischen Bereich vorteilhaft um rückblickend die einzelnen Entwicklungsschritte klar voneinander unterscheiden zu können. Mittlerweile wird diese Funktion von den meisten²⁹ Versionskontrollsystemen unterstützt.

Von Bedeutung sind auch die unterstützten Netzwerkprotokolle. Die Unterstützung von HTTP ist aus zwei Gründen von Vorteil: einerseits erfordert es keinen zusätzlichen Installationsaufwand auf Seiten des Kunden, da bei vorhandener Internetanbindung das Protokoll bereits installiert ist und andererseits sind – man kann fast sagen alle – Firewalls für die entsprechenden HTTP-Ports offen, d.h. es fällt auch kein zusätzlicher Konfigurationsaufwand an. HTTP-Unterstützung ermöglicht also eine ganz einfache Integration, ist aber auch mit einem Nachteil behaftet und zwar der fehlenden Verschlüsselung. Dies kann jedoch durch die Verwendung von SSL (HTTPS) ausgeglichen werden. Während HTTP von etlichen³⁰ Versionskontrollsystemen unterstützt wird, erlauben nur einige³¹ auch HTTPS-Verbindungen.

Selbstverständlich können nur Bruchteile der legistischen Vorgaben automationsuntersüttzt überprüft werden. Vor allem in inhaltlicher Hinsicht kommt man nicht an der Qualitätsprüfung durch den Menschen vorbei. Trotzdem kann auch hier die juristische Arbeit wesentlich effizienter gestaltet werden, indem beispielsweise die Stellungnahme zu den einzelnen Entwurfspassagen online erfolgt. Dabei könnte verlangt werden, diese Stellungnahmen zu kategorisieren. So ist die Arbeit für die verantwortliche Person auf die inhaltliche Beurteilung der Vorschläge und allenfalls eine sprachliche Überarbeitung beschränkt. Die Zuordnung der Stellungnahmen sowie die Auswertung im Rahmen einer Berichtsfunktion können ohne Zutun der für den Entwurf verantwortlichen Personen erfolgen. Egal ob zu einem Gesetzes-, Urteils- oder Vertragsentwurf Stellung genommen werden soll – die Nachvollziehbarkeit und Übersichtlichkeit des Ausarbeitungprozesses werden stark verbessert.

Bei der Erstellung von Software werden schon seit Jahren sogenannte Software Configuration Management Systeme eingesetzt, die ein effizientes Zusammenarbeiten von Teams ermöglichen und Funktionen zur Fehleranalyse und -vermeidung anbieten. Dieser Beitrag untersucht, inwieweit diesebest practices aus der Informatik in die Rechtswissenschaft übernommen werden können.

Ein solches «Legal Configuration Management System» soll die juristischen Mitarbeiter vom Dokumentenmanagement sowie der Einhaltung der formellen Vorgaben so weit als möglich entlasten. Dazu sind im Wesentlichen drei Komponenten erforderlich:

1. ein Versionskontrollsystem, das alle Änderungen überwacht und jeweils einer Person zuordnet,
   
2. ein juristischer Editor, der bei der Einhaltung der formellen Vorgaben unterstützt und die Ausarbeitung juristischer Texte beschleunigt sowie
   
3. ein Validierungs- und Berichtswerkzeug, das externen Input in das Versionskontrollsystem einträgt bzw. aus den Daten des Versionskontrollsystems sinnvolle Berichte generieren kann.

Mit diesem Ansatz soll die Effizienz der juristischen Arbeit von Legisten, Rechtsanwälten, Richtern und Verwaltungsbeamten gesteigert werden, auch wenn mit den heutigen Methoden der Informatik wenig zur inhaltlichen Arbeit der Juristen beigetragen werden kann.

Berczuk S.P./Appleton B., Software Configuration Management Patterns – Effective Teamwork, Practical Integration, Pearson Education, Inc., Boston (2003).

Buck E.M./Yacktman D.A., Cocoa Design Patterns, mitp, Heidelberg (2010).
Bundeskanzleramt-Verfassungsdienst (Hrsg.), Legistische Richtlinien 1990.http://www.bka.gv.at/DocView.axd? CobId=1656 aufgerufen 20.12.2010 (1990).

Bundesministerium für Justiz (Hrsg.), Handbuch der Rechtsförmlichkeit3.http://hdr.bmj.de/vorwort.html aufgerufen 20. Dezember 2010 (2008).

Friedl, G./Loebenstein, H., Abkürzungs- und Zitierregeln der österreichischen Rechtssprache und europarechtlicher Quellen5, Manz, Wien (2001).

Hausmanninger C./Petsche A./Vartian C./Nowotny C./Winkler O. (Hrsg.), Wiener Vertragshandbuch I – III, Manz, Wien (2007).

Ickler T., Die Disziplinierung der Sprache: Fachsprachen in unserer Zeit, Gunter Narr Verlag, Tübingen (1997).

Schuhr J., Rechtsdogmatik als Wissenschaft: rechtliche Theorien und Modelle, Duncker & Humblot, Berlin (2006).

Schweizerische Bundeskanzlei (Hrsg.), Gesetzestechnische Richtlinien des Bundes.http://www.bk.admin.ch/themen/gesetz/00050/index.html?lang=de&download=M3wBPgDB_8ull6Du36WenojQ1NTTjaXZnqWfVpzLhmfhnapmmc7
Zi6rZnqCkkIN5e32CbKbXrZ6lhuDZz8mMps2gpKfo aufgerufen 20. Dezember 2010 (2003).

Sharp A., Smalltalk by Example – The Developer’s Guide, McGraw Hill, New York (1997).

Walter, Vorarbeiten zu einer Reform der Legistischen Richtlinien 1979, Schriftenreihe zur Verwaltungsreform XI, Bundeskanzleramt, Wien (1985).

---

Intelligent Law and Internet Applications (ILIA)
Landhausstrasse 6, 9000 St. Gallen, CH
office@ilia.ch ,http://www.ilia.ch

---