xjustiz_techdok_2005-12-27_v131.pdf - OSCI

20. Dezember 2005 

Arbeitsgruppe IT-Standards in der Justiz 

Technische Dokumentation zu XJustiz Version 1.3.1 

I. Einleitung ....................................................................................................... 3 

Allgemeines........................................................................................................ 3 

1. Grundzüge des Lösungsansatzes.................................................................. 3 

2. Bestandteile von XJustiz................................................................................ 3 

II. Aufbau und Inhalt der XML-Schema-Dateien .............................................. 5 

1. Namensraum ................................................................................................. 5 

2. Grundmodul, Wertelisten und Fachmodule.................................................... 6 

a) Grundmodul............................................................................................... 6 

b) Wertelisten................................................................................................10 

c) Fachmodule..............................................................................................12 

d) Include-Technik ........................................................................................17 

e) Import-Technik..........................................................................................18 

3. Bezugnahme auf die Schemata in Instanzdokumenten................................19 

4. Statisches Datenmodell ................................................................................19 

5. Bewusst ausgeklammerte Aspekte...............................................................20 

a) Dokumente und Meta-Informationen ........................................................20 

b) Elektronische Signatur..............................................................................21 

c) Übertragungsweg, Verschlüsselung, Transportsignatur ...........................21 

III. Einzelheiten...................................................................................................21 

1. Dateinamen ..................................................................................................21 

2. Modellierungsstil ...........................................................................................23 

3. Häufigkeiten (Kardinalitäten).........................................................................25 

a) minOccurs und maxOccurs ......................................................................25 

b) Leere Elemente ........................................................................................26 

c) Leerstrings................................................................................................27 

4. Interne Referenzierung .................................................................................28 

a) Ausgangspunkt.........................................................................................28 

b) Eingesetzte Werkzeuge............................................................................29 

5. Erweiterung und Einschränkung ...................................................................37 

a) Erweiterung ..............................................................................................37 

b) Einschränkung..........................................................................................38 

6. Versionierung................................................................................................39 

a) Versionierung der Schema-Dateien..........................................................39 

b) Wiedergabe der Versionsnummer in Instanzdokumenten ........................41 

7. Parser ...........................................................................................................43 

IV. Abbildungsverzeichnis: ...............................................................................44 

doku/xjustiz_techdok_2005-12-27_v131.doc

XJustiz Version 1.3 Technische Dokumentation 2 

Versionsangaben 

Version 1.3.1 

Stand vom 20.12.2005 

Bearbeitet von 

OSCI Leitstelle Bremen 

Status 

Vorlage an AG-IT 

Freigegeben AG-IT am 

Freigegeben BLK am 

Änderungshistorie 

Datum Was wurde geändert Wer hat geändert 

19.09.2003 Neuerstellung Irina Bauer 

28.09.2003 Redaktionelle Überarbeitung Klaus Bacher 

13.10.2003 Angaben zu Version und Änderungshistorie 

eingefügt 

Klaus Bacher 

15.10.2003 Änderungen auf Vorschlag NRW eingefügt Klaus Bacher 

05.11.2003 Freigabe BLK, V1.1 erstellt Jürgen Ehrmann 

06.10.2004 Anpassung an die neue Version des 

Grunddatensatzes V1.2 

30.05.2005 Anpassungen an die neue Version des 

Grunddatensatzes V1.3 mit Verwendung 

von XDOMEA 

20.12.2005 Anpassungen an Version 1.3.1: veränderte 

Identity Constraints aufgrund Validierungsmeldungen 

von Parsern mit Version 

1.3.0 

Irina Bauer 

Irina Bauer 

Irina Bauer 



I. Einleitung 

Allgemeines 

Das Datenformat XJustiz soll im Elektronischen Rechtsverkehr den Austausch von verfahrensrelevanten 

Daten zwischen Gerichten, Staatsanwaltschaften und Verfahrensbeteiligten 

nach einem bundesweit einheitlichen Standard ermöglichen. 

Die Zielsetzung und die Rahmenbedingungen von XJustiz werden in der Anlage 2 der Organisatorisch-technischen 

Leitlinien für den elektronischen Rechtsverkehr (OT-Leit ERV), 

dem XJustiz Leitfaden dargestellt. Die OT-Leit ERV und ihre Anlagen können unter 

www.xjustiz.de in der aktuellen Version abgerufen werden. 

Zur Rekonstruktion voriger Versionsstände dient die Versionshistorie, die unter 

http://www.xjustiz.de/xjustiz_historie.htm abzurufen ist. Hier sind Erläuterungen und Hinweisen 

zu alternativen Dateiversionen aufgeführt. 

1. Grundzüge des Lösungsansatzes 

XJustiz bedient sich der Auszeichnungssprache XML (Extensible Markup Language). Daten, 

die im Format XJustiz übermittelt werden, sind in einer XML-Datei (einem so genannten 

Instanzdokument) enthalten, die nach bestimmten Regeln aufgebaut ist. Diese Regeln 

ihrerseits sind in Dateien hinterlegt, die nach dem Standard XSD (XML-Schema-Datei) 

aufgebaut sind. 

Im Folgenden wird beschrieben, nach welchem Prinzip die für XJustiz maßgeblichen XML- 

Schema-Dateien aufgebaut sind und welche Besonderheiten es bei der Erstellung von Instanzdokumenten, 

die diesen Schemata entsprechen, zu beachten gilt. 

2. Bestandteile von XJustiz 

Die Definition der XJustiz-Datenstrukturen ist derzeit in folgenden XML-Schema-Dateien 

hinterlegt: 



▪ 

Grundmodul (xj_0000_grunddatensatz_1_3.xsd) 

Dies ist eine XML-Schema-Datei in der grundlegende Strukturen und Datentypen definiert 

werden. Die in dieser Datei enthaltenen Definitionen bilden die Grundlage für die 

einzelnen Fachdatensätze. 

▪ 

Verschiedene Wertelisten 

Diese Listen werden zum Ausfüllen einzelner Felder benötigt, in denen nur bestimmte 

Angaben zulässig sind (z.B. Abkürzungen für Ländernamen nach ISO 3166). Diese 

Wertelisten sind ebenfalls als XML-Schema-Datei angelegt. Aus Gründen der Übersichtlichkeit 

wurden die Listen auf folgende Dateien verteilt: 

▪ xj_0010_wl_allgemein_1_3.xsd 

▪ xj_0020_wl_gerichte_1_3.xsd 

▪ xj_0030_wl_rechtsform_1_3.xsd 

▪ xj_0040_wl_rollenbezeichnung_1_3.xsd 

▪ xj_0050_wl_staaten_1_3.xsd 

▪ xj_0060_wl_telekommunikation_1_3.xsd 

▪ xj_0070_wl_justizvollzugsanstalt_1_3.xsd 

▪ 

Basis-Fachmodul (xj_0100_basis_1_3.xsd) 

Dies ist eine XML-Schema-Datei, in der die im Grundmodul enthaltenen Definitionen 

sowie die Vorgaben aus den Wertelisten ohne Ergänzungen oder Einschränkungen 

umgesetzt worden sind. 

Das Basis-Fachmodul ist die zentrale Vorgabe für alle XJustiz-Datensätze, die im 

Grundmodul definierten Informationen ohne weitergehende Zusätze enthalten. 

▪ 

Fachmodul Familie (xj_0200_familie_1_3.xsd) 

Das Fachmodul Familie tritt in Familiensachen an die Stelle des Basis-Fachmoduls. Es 

hat dieselbe Struktur wie dieses, enthält als Erweiterung aber zusätzliche Definitionen 

für Daten-Elemente, die nur in Familiensachen benötigt werden. 



▪ 

Wertelisten für das Fachmodul 

Für das Fachmodul Familie existieren familienspezifische Wertelisten. 

▪ xj_0210_wl_gegenstand_1_3.xsd 

▪ 

xj_0220_wl_rollenbezeichnung_1_3.xsd 

II. 

Aufbau und Inhalt der XML-Schema-Dateien 

1. Namensraum 

Alle Bezeichnungen innerhalb einer XML-Datei müssen einem bestimmten Namensraum 

zugeordnet sein, um sie eindeutig identifizieren zu können. Hierzu wird der Bezeichnung 

ein Präfix vorangestellt, der den Namensraum kennzeichnet. 

Das Vokabular der Definitionssprache XML Schema selbst wird durch den Namensraum 

www.w3.org.2002/XMLSchema identifiziert. Um Schreibaufwand zu sparen und den Code 

übersichtlicher zu halten, wird für diesen Namensraum in XJustiz – einer allgemeinen Ü- 

bung entsprechend – das Präfix xs: verwendet. 

Ergänzend kann ein bestimmter Namensraum als Standard definiert werden. Diesem Namensraum 

ist definitionsgemäß das Präfix xmlns: zugeordnet. In XJustiz lautet der Standard-Namensraum 

http://www.xjustiz.de. 

Globale Objekte, die keinen Präfix haben, werden automatisch dem Präfix xmlns: zugeordnet. 

Lokal deklarierte Elemente werden ihm nur dann zugeordnet, wenn das Attribut e- 

lementFormDefault den Wert qualified hat. Dies ist in XJustiz der Fall. Lokal deklarierte Attribute 

werden dem Standard-Namensraum zugeordnet, wenn das attributeFormDefault den 

Wert qualified hat. Dies ist in XJustiz nicht der Fall. 

Schließlich kann noch ein Ziel-Namensraum (targetNamespace) definiert werden. Dies ist 

der Standard-Namensraum für die zum Schema gehörigen Instanzdokumente. In XJustiz 

lautet auch der Ziel-Namensraum http://www.xjustiz.de. Damit sind alle zu XJustiz gehörigen 

Objekte einem einheitlichen Namensraum zugeordnet. Dies vereinfacht die Erweiterung 

durch Vererbung von Typen und die Anbindung von externen Listen. 



Eine Sonderstellung nehmen die Elemente im Zweig XDOMEA ein. Diese stammen aus 

dem Namensraum http://www.xdomea.de. Diesem Namensraum ist in XJustiz das Kürzel 

xdo zugeordnet. Einzelheiten dazu werden unten unter 2.e) dargestellt. 

2. Grundmodul, Wertelisten und Fachmodule 

Die Definition der XML-Strukturen ist auf mehrere Dateien verteilt. 

a) Grundmodul 

Das Grundmodul ist eine Art Baukasten. Es definiert die Grundstrukturen und stellt diese 

als Sammlung von Bausteinen zur Verfügung, auf die die einzelnen Fachmodule zurückgreifen 

können. 

(1) Grundlegender Aufbau 

Programmiertechnisch gesehen ist das Grundmodul eine Sammlung von komplexen Datentypen. 

Die meisten dieser Typen sind stark hierarchisch aufgebaut, d.h. die in ihnen enthaltenen 

Elemente sind in einer über mehrere Ebenen gegliederten Baumstruktur angeordnet. 

Auf diese Weise wird ein den Erfordernissen des Rechtsverkehrs entsprechendes Inhaltsmodell 

aufgebaut. 

Das Grundmodul besitzt kein Wurzelelement. Es kann deshalb nicht als Ausgangspunkt 

für die Erstellung oder Prüfung einer XML-Datei verwendet werden. Für diese Zwecke muss 

das Grundmodul vielmehr um ein Fachmodul ergänzt werden. 

Ergänzt wird das Grundmodul durch eine Sammlung von Wertelisten, in denen für den Inhalt 

bestimmter Elemente (z.B. Familienstand oder Staatsangehörigkeit) standardisierte 

Werte vorgegeben werden. Inhaltlich sind diese Wertelisten integraler Bestandteil. Um den 

Code besser lesbar zu halten, wurden die Wertelisten aber in separate Dateien ausgelagert. 

(2) Wesentliche Datentypen 

Zentraler Ankerpunkt des Grundmoduls ist der Typ T_Grunddaten. Er enthält das Element 

Grunddaten, in dem alle im Grundmodul definierten Datentypen zusammengefasst und den 



fachlichen Vorgaben entsprechend angeordnet sind. Aus fachlichen Überlegungen heraus 

wurde das Element Grunddaten wie folgt strukturiert: 

Das Element Grunddaten enthält die Unterelemente Verfahren und Sendung. 

Das Unterelement Verfahrensdaten definiert Informationen, die für das von der Datenübermittlung 

betroffene Verfahren relevant sind. Es enthält seinerseits folgende Unterelemente: 

▪ Verfahrensnummer 

▪ Instanzdaten 

▪ Beteiligung 

▪ Termin 

Das Unterelement Sendungsdaten definiert Meta-Informationen, für den einzelnen Übermittlungsvorgang. 

Es enthält seinerseits folgende Unterelemente: 

▪ Sendungsprioritaet 

▪ Sendungsinhalt 

▪ Bemerkung 

▪ Absenderkennung 

▪ Empfaengerkennung 

▪ Eingangsbestaetigungswunsch 

▪ Papiervorgang 

▪ XDOMEA 

Der vorstehend beschriebene Grundaufbau ist in nachfolgendem Schaubild nochmals zusammengefasst: 



Abbildung 1a: Aufbau des Elements T_Grunddaten 



Die Struktur von XDOMEA ist der folgenden Abbildung zu entnehmen. 

Abbildung 2b: Aufbau des Elements XDOMEA 

Daneben enthält das Grundmodul eine Ansammlung von global definierten Typen. Dabei 

handelt es sich um kleinere Datenstrukturen, die innerhalb des Typs T_Grunddaten öfter 

Verwendung finden oder deren Wiederverwendung in künftigen Fachmodulen wahrscheinlich 

und sinnvoll erscheint. Ein Beispiel bildet der Typ T_Bankverbindung. An verschiedenen 

Stellen des Grundmoduls werden Elemente definiert, die Angaben zu einer Bankverbindung 

enthalten. Die Definition des Typs T_Bankverbindung ermöglicht es, diese Strukturen mit 

einfachen Mittel gleich auszugestalten. Zugleich erleichtert sie die spätere Pflege. Werden 

für eine Bankverbindung später zusätzliche oder andere Daten benötigt, muss nur der Typ 

neu definiert werden, nicht dagegen die zahlreichen Elemente, die diesem Typ zugewiesen 

sind. 



Außerdem sind im Grundmodul Wertelistentypen definiert (gekennzeichnet mit WLT_). 

Diese bilden die Grundlage für die Einbindung von Wertelisten. Siehe dazu im Einzelnen 

unter b). 

Eine vollständige Übersicht über sämtliche im Grundmodul definierten Datentypen liefert 

das folgende Schaubild: 

Abbildung 3: Datentypen im Grundmodul 

b) Wertelisten 

Wertelisten dienen dazu, für den Inhalt bestimmter Elemente eine Menge von zulässigen 

Werten zu definieren. Typische Beispiele sind Elemente wie Staatsangehörigkeit oder Familienstand, 

die typischerweise nur bestimmte Werte enthalten können und sollten. 



Die zum Grundmodul gehörigen Wertelisten wurden der Übersichtlichkeit halber in separate 

Dateien ausgelagert. Dabei wurde für umfangreichere Listen jeweils eine gesonderte 

Datei angelegt. Kleinere Listen wurden in der Datei xj_0010_wl_allgemein_1_3.xsd zusammengefasst. 

Im Einzelnen gehören zum Grundmodul folgende Wertelisten-Dateien: 

▪ xj_0010_wl_allgemein_1_3.xsd 

▪ xj_0020_wl_gerichte_1_3.xsd 

▪ xj_0030_wl_rechtsform_1_3.xsd 

▪ xj_0040_wl_rollenbezeichnung_1_3.xsd 

▪ xj_0050_wl_staaten_1_3.xsd 

▪ xj_0060_wl_telekommunikation_1_3.xsd 

▪ xj_0070_wl_justizvollzugsanstalt_1_3.xsd 

Die Datei wl_allgemein_1_3.xsd enthält Wertelisten für folgende Elemente: 

▪ Anschriftstyp 

▪ Dateiformat 

▪ Familienstand 

▪ Geschlecht 

▪ Sachgebiet 

▪ Sendungsinhalt 

▪ Terminsart 

Der Inhalt der anderen Wertelisten-Dateien ergibt sich aus dem Dateinamen. 

Jede Werteliste definiert einen Datentyp auf der Basis des im Grundmodul enthaltenen 

Typs WLT_String und schränkt diesen durch Enumerations, also durch Vorgabe einer abschließenden 

Liste von zulässigen Werten, ein. Alle auf diese Art definierten Datentypen 

tragen Namen, die mit WL_ beginnen. 

Der Basis-Typ WLT_String wird hier verwendet, weil er neben einer String-Information auch 

Attribute enthält, aus denen die Version und die Fassung der jeweils verwendeten Wertelis- 


XJustiz Version 1.3 Technische Dokumentation 12 

te hervorgeht. Auf diese Weise können neue Versionen der Wertelisten eingeführt werden, 

ohne dass der Inhalt des Grundmoduls geändert werden muss. Für die Elemente Gericht 

und Rollenbezeichnung wurden spezielle Basistypen WLT_Gerichte und 

WLT_Rollenbezeichnung geschaffen, weil diese Elemente zugleich Teil von Identity 

Constraints (Unique) sind (vgl. dazu III.4). 

In einigen Fällen könnte sich die Verwendung verbindlicher Wertelisten in der Praxis als zu 

starr erweisen. Beispielsweise könnte kurzfristig die Notwendigkeit entstehen, eine neue 

Staatenbezeichnung zu verwenden, die in der einschlägigen Werteliste noch nicht enthalten 

ist. Um für solche Situationen genügend Flexibilität zu haben, besteht für jedes Instanz- 

Dokument die Möglichkeit, anstelle des in der Werteliste verwendeten Datentyps WL_xxx 

den Basistyp WLT_String zu verwenden, der beliebige Inhalte zulässt. Einzelheiten hierzu 

sind unter c) beschrieben. 

c) Fachmodule 

(1) Funktion und grundlegender Aufbau 

Weder das Grundmodul noch die zu diesem gehörigen Wertelisten sind als unmittelbarer 

Ansatzpunkt für die Definition eines Instanzdokuments geeignet. Hierzu ist ein so genanntes 

Root-Element erforderlich, das diese Dateien – ihrer Zwecksetzung als "Werkzeugsammlung" 

entsprechend – nicht aufweisen. 

Um ein Instanzdokument definieren und prüfen zu können, werden Fachmodule eingesetzt. 

Die Fachmodule beziehen sich über einen include-Befehle auf das Grundmodul, das 

seinerseits wiederum mit Inklusionen die zugehörigen Wertelisten an sich zieht Hierdurch 

stehen sämtliche Datentypen und Definitionen aus dem Grundmodul und den Wertelisten 

im Fachmodul zur Verfügung. 

Die include-Beziehungen zwischen den einzelnen Elementen von XJustiz sind in der nachfolgenden 

Grafik nochmals veranschaulicht: 



Anbindung der Wertelisten 

Fachmodul 

Grundmodul 

xs:include 

Wertelisten 

Werteliste 2 

Werteliste 3 

Werteliste 4 

Werteliste 5 

Werteliste 6 

xs:include 

Werteliste 

Wertelisten 

2 

für 

Fachmodul 

xs:include 

Abbildung 4: Einbindung des Grundmoduls und der Wertelisten 

Jedes Fachmodul enthält das Root-Element XJustizDaten. Dieses wiederum besteht aus 

einem Unterelement Grunddaten und einem zusätzlichen Element Fachdaten_xxx. 

Das Element Grunddaten ist vom Datentyp T_Grunddaten, enthält also sämtliche Unterelemente 

und sonstigen Merkmale, die im Grundmodul definiert sind. Je nach den fachlichen 

Anforderungen können die im Grundmodul enthaltenen Definitionen dabei eingeschränkt, 

erweitert oder modifiziert sein. 

Das Element Fachdaten_xxx enthält zusätzliche Elemente, die nur für das jeweilige Fachverfahren 

benötigt werden. 

Zusammen mit der XJustiz-Version 1.0 sind zwei Fachmodule erstellt worden: 



(2) Basis-Fachmodul 

Das Basis-Fachmodul enthält das Element Grunddaten in unveränderter Form, stellt also 

eine Eins-Zu-Eins-Abbildung der im Grundmodul enthaltenen Definitionen zur Verfügung. 

Es eignet sich zur Aufnahme des elektronischen Rechtsverkehrs in allen Gerichtszweigen 

und Verfahrensarten, solange für das jeweilige Fachgebiet noch kein Fachmodul existiert. 

Als einzige Ergänzung zum Element Grunddaten enthält das Basis-Fachmodul ein Element 

Fachdaten_Basis. Dieses ist vom Datentyp any, kann also beliebigen Inhalt haben. 

Der Aufbau des Basis-Fachmoduls ist in der nachfolgenden Grafik nochmals zusammengefasst: 

Abbildung 5: Aufbau des Basis-Fachmoduls 

(3) Fachmodul Familie 

Das Fachmodul Familie enthält zusätzliche Elemente und Definitionen, die nur in Verfahren 

vor den Familiengerichten benötigt werden. Hierzu wird die Definition des Elements Grunddaten 

teilweise abgewandelt. Außerdem definiert das Element Fachdaten_FAM zusätzliche 

Datenstrukturen, die im Grundmodul nicht angelegt sind. 

Der Aufbau des Fachmoduls Familie ist in der nachfolgenden Grafik dargestellt. 



Abbildung 6: Aufbau des Fachmoduls Familie 

Die bereits vorliegenden Fachmodule in ihren jeweiligen Versionen sind folgende: 

- XJustiz.Basis: xj_0100_basis_1_3.xsd 

- XJustiz.Familie: xj_0200_familie_1_3.xsd 

- XJustiz.Insolvenz: xj_0300_insolvenz_1_3.xsd 

- XJustiz.Register: xj_0400_register_1_1.xsd 

Zusammen mit der XJustiz-Version 1.3.0 ist das Fachmodul für Straf erstellt worden. 

- XJustiz.Straf: xj_0500_straf_1_0.xsd 

(4) Anbindung der Wertelisten 

Die für bestimmte Elemente im Grunddatensatz definierten Wertelisten sind im Fachdatensatz 

automatisch durch den Verweis auf den Grunddatensatz zur Verfügung gestellt. (Indirekte 

Inklusion) Innerhalb des Fachdatensatzes besteht die Möglichkeit, diese Wertelisten 



nochmals einzuschränken oder zu erweitern, um sie den Erfordernissen des jeweiligen 

Fachgebiets anzupassen. 

Alle fachspezifischen Wertelisten werden über eine direkte Inklusion an das Fachmodul 

gebunden. Im Fachmodul Familie wurde von dieser Möglichkeit beispielsweise für die Werteliste 

Gegenstandsbezeichnung Gebrauch gemacht. Diese Werteliste liegt in 

xj_0210_wl_gegenstand_1_3.xsd 

Um bei der Verwendung von Wertelisten ein Mindestmaß an Flexibilität zu bewahren, sind 

die im Grundmodul definierten Elemente nicht an einen bestimmten Wertelistentyp gebunden. 

Elemente, für die die Verwendung von Wertelisten in Betracht kommt, weisen stattdessen 

den Typ WLT_String (oder die strukturgleichen Typen WLT_Gerichte und 

WLT_Rollenbezeichnung) auf, der beliebige Stringwerte zulässt und darüber hinaus Versions-Attribute 

vorsieht. Soll anstelle dieses "offenen" Datentyps ein Wertelistentyp aus den 

inkludierten Wertelisten verwendet werden, muss dies im Instanzdokument durch Verwendung 

des Attributs xsi:type kenntlich gemacht werden. 

In der Regel enthalten Instanzdokumente keine Angaben über den Datentyp der in ihnen 

enthaltenen Elemente. In diesem Fall ergibt sich der Datentyp aus den Definitionen des zu 

Grunde liegenden XML-Schemas. Das Attribut xsi:type ermöglicht es, den Datentyp im Instanzdokument 

explizit festzulegen. Hierbei kann ein anderer Datentyp gewählt werden als 

der im XML-Schema vorgesehene. Dies funktioniert jedenfalls dann problemlos, wenn die 

beiden Datentypen dieselbe Grundstruktur aufweisen. Um letzteres zu gewährleisten, wird 

für die in Frage kommenden Elemente bereits im Grundmodul nicht der einfache Datentyp 

xs:string verwendet, sondern der speziell definierte Typ WLT_String, der zusätzlich Attribute 

vorsieht, mit denen eine Versionsnummer angegeben werden kann. 

Alle Wertelisten-Typen enthalten ein Attribut wl_version. Damit kann (und muss) angegeben 

werden, welche Version (Haupt- und Unterversion, vgl. unten III.6) der jeweiligen Wertelistentyp 

bei der Erstellung des Instanzdokuments zu Grunde gelegt worden ist. Ergänzend 

ist ein optionales Attribut wl_fassung vorgesehen, mit dem angegeben wird, in welcher 

konkreten inhaltlichen Fassung die Werteliste zu Grunde gelegt worden ist. 



Die vorstehend beschriebene Vorgehensweise lässt sich an folgendem Beispiel verdeutlichen: 

Dem an verschiedenen Stellen vorgesehenen Element Staat ist im Grundmodul der Datentyp 

WLT_String zugewiesen. Sofern das Instanzdokument dazu keine zusätzlichen Festlegungen 

enthält, kann dieses Element im Instanzdokument deshalb beliebigen Inhalt haben. 

Auch die Verwendung eines Attributs ist dann nicht zwingend erforderlich. Zulässig wäre 

beispielsweise folgende Angabe: 

Irgendein neu gegründeter Staat 

Im Instanzdokument kann (und sollte in aller Regel) stattdessen aber festgelegt werden, 

dass das Element dem Datentyp WL_Staat entspricht, also einen vordefinierten Wert enthält. 

Dann hat das Element beispielsweise folgenden Inhalt: 

DE 

Bei der Erstellung von Instanzdokumenten soll in aller Regel auf vorhandene Wertelisten 

zugegriffen werden. Nur in Ausnahmefällen, in denen die Werteliste den aus inhaltlicher und 

fachlicher Sicht benötigten Wert nicht enthält, darf der Basistyp WLT_String verwendet werden. 

d) Include-Technik 

Für die Einbindung des Grundmoduls in die Fachmodule sowie für die Einbindung der Wertelisten 

in das Grundmodul wird die Anweisung xs:include verwendet. Wichtig bei der Verwendung 

von xs:include ist, dass das eingebundene Schema denselben Ziel- 

Namensraum haben muß wie das einbindende Schema. Es ist möglich gleichzeitig 

mehrere Dokumente mit mehreren Include-Elementen einzubinden und Dokumente, die 

ihrerseits wieder inkludieren - jedoch müssen alle eingebundenen Dokumenten denselben 

Ziel-Namensraum verwenden. Das Inkludieren eines Schemadokumentes erzeugt eine 

Referenz auf dieses und erlaubt somit später einen schnelleren Zugriff, da hier vorab in den 

Cache gespeichert wird. 



Die Einbindung mittels xs:include bietet sich auch für künftige Erweiterungen von XJustiz 

an, insbesondere für zukünftig hinzukommende Fachmodule. Sollten in Zukunft XJustiz- 

Module mit einem eigenem, neuen Namensraum hinzukommen, müssten diese Module hingegen 

mit der Anweisung xs:import importiert werden. Aus heutiger Sicht erscheint es indes 

sinnvoller, auch neue XJustiz-Module in den einheitlichen Namensraum 

http://www.xjustiz.de zu integrieren und deren Anbindung an andere Module über xs:include 

zu realisieren. 

Für die Einbindung externer Strukturen wie z.B. XDOMEA bietet sich dagegen die Import- 

Technik an. 

e) Import-Technik 

Die Einbindung mittels xs:import bietet die Möglichkeit, einen ganzen externen 

Namensraum zu importieren. Die verschiedenen Namensräume können dann mittels 

vorangestellten Präfixen voneinander unterschieden werden. So können gleiche oder 

identische Bezeichner, die möglicherweise in ihren jeweiligen Namensräume verschiedene 

Bedeutungen haben über ihr Präfix dem korrekten Namensraum zugeordnet werden. 

Bei XJustiz wird ab der Version 1.3.0 die Import-Anweisung eingesetzt, um XDOMEA 

einzubeziehen. XDOMEA ist eine Datensatzbeschreibung, die für den Austausch von 

Dokumenten, Akten und Vorgängen in der öffentlichen Verwaltung insgesamt vorgesehen 

ist. XJustiz verwendet diese Strukturen, indem im Element Sendungsdaten an Stelle des 

bisherigen justizspezifischen Unterelements Dokument ein neues Unterelement XDOMEA 

eingefügt wurde, das vollständig der XDOMEA-Definition entspricht. Hierzu wurde die XDO- 

MEA-Definition mit Hilfe der Anweisung xs:import in XJustiz integriert. Der Namensraum für 

dieses importierte Element lautet http://www.xdomea.de, das entsprechende Präfix lautet 

xdo. 

" xmlns:xdo="http://www.xdomea.de" 



Zur Kennzeichnung des Namensraums muss allen Unterelementen des XDOMEA-Zweigs 

in XJustiz-Datensätzen das Präfix xdo: vorangestellt werden. In „reinen“ XDOMEA- 

Datensätzen ist dieses Präfix nicht erforderlich (weil dort http://www.xdomea.de der 

Standard-Namensraum ist), aber auch nicht schädlich. 

3. Bezugnahme auf die Schemata in Instanzdokumenten 

Jedes XML-Instanzdokument muss die Angabe enthalten, nach welchen Regeln es aufgebaut 

ist. Hierzu muss im Instanzdokument auf eines der Fachmodule referenziert werden. 

Diese Referenzierung erfolgt durch das Attribut xsi:schemaLocation. Als Wert enthält es 

Paare aus einem Namensraum (www.xjustiz.de) und einer Referenz auf ein zu diesem Namensraum 

gehöriges Fachmodul. 

Auf das Grundmodul oder auf Wertelisten braucht in Instanzdokumenten dagegen nicht referenziert 

zu werden. Beides steht durch die Inklusionskette des Fachmoduls und die darin 

enthaltene xs:include-Anweisung auf das Grundmodul und die hier implizit inkludierten Wertelisten 

automatisch zur Verfügung. Auch eine Referenzierung auf das XDOMEA-Schema 

ist nicht erforderlich. Dieses steht aufgrund der xs:import-Anweisung im Grundmodul ebenfalls 

automatisch zur Verfügung. 

4. Statisches Datenmodell 

Die Definitionen in XJustiz sind von statischer Natur. Sie dürfen deshalb nur als statisches 

Datenmodell gesehen werden. Erste Entwürfe von XJustiz hatten demgegenüber noch Mechanismen 

vorgesehen, die eine rudimentäre Grundlage für die Mitteilung von Änderungsoder 

Lösch-Vorschlägen geboten hätten. Diese Ansätze wurden verworfen, weil sie ihre 

Umsetzung nach Einschätzung von Software-Entwicklern mit zu hohem Aufwand verbunden 

gewesen wäre. 

In seiner jetzigen Form macht XJustiz keine Annahmen über die EDV-Ausstattung auf Anwalts- 

und oder Gerichtsseite, über Inhalt und Umfang der dort vorhandenen Datenbestände 

oder über bestimmte Eigenschaften von Fachanwendungen. XJustiz hat lediglich die 



Funktion einer Schnittstelle, über die die verschiedenen Anwendungen statische Daten 

austauschen können. Mit XJustiz können dagegen keinerlei Transaktionen ausgelöst 

werden. XJustiz ist also beispielsweise nicht dafür ausgelegt, durch den Eingang eines Instanzdokuments 

automatische Transaktionen in der Gerichtsdatenbank auszulösen. 

Im Rahmen einer späteren Erweiterung ist denkbar, auch Transaktionen zu modellieren. 

Hierzu bietet sich die Verwendung von separaten Transaktions-XML-Schemata an. 

5. Bewusst ausgeklammerte Aspekte 

Die Konzeption von XJustiz beschränkt sich bewusst darauf, lediglich eine Datenstruktur 

für den Austausch ausgewählter Daten bereitzustellen. Andere Aspekte, die für eine rechtsgültige 

Übermittlung im elektronischen Rechtsverkehr einer Lösung bedürfen, wurden bewusst 

ausgeklammert, um den Inhalt der Vorgaben auf ein Minimum zu beschränken. 

Für alle Aspekte, die von XJustiz nicht berührt werden, ergeben sich die maßgeblichen Vorgaben 

aus den von der Bund-Länder-Kommission für Datenverarbeitung und Rationalisierung 

in der Justiz (BLK) verabschiedeten Organisatorisch-Technischen Leitlinien elektronischen 

Rechtsverkehr mit den Gerichten und Staatsanwaltschaften (OT-Leit-ERV). Dieses 

Regelwerk, das auch einen technischen Anhang enthält, ist unter anderem unter 

http://www.xjustiz.de erhältlich. 

a) Dokumente und Meta-Informationen 

Die in XJustiz definierten Strukturen beschreiben ausschließlich Meta-Informationen zu 

einem übermittelten Dokument und zu dem Verfahren, auf das sich das Dokument bezieht. 

Das eigentliche Dokument ist in einer separaten Datei enthalten, das nicht im XJustiz- 

Format erstellt ist. Zusammen mit jeder XJustiz-Instanzdatei wird deshalb in aller Regel 

mindestens eine weitere Datei übertragen, die das eigentlich zu übermittelnde Dokument 

enthält. 

Beispiel: Wenn ein Anwalt eine Klage einreicht, erstellt er die Klageschrift in einem gängigen 

Dokumentenformat, z.B. Adobe PDF. Welche Formate hierfür zulässig sind, wird durch 



Rechtsverordnung geregelt. Zu diesem Dokument wird vor dem Versand eine XJustiz-Datei 

erzeugt, in der grundlegende Informationen zum Absender und Empfänger des Dokuments 

Sendung sowie rudimentäre Angaben zu dessen Inhalt hinterlegt werden. Beides zusammen 

– Klageschrift im PDF-Format und Metainformationen im XJustiz-Format wird dann an 

das Gericht übersandt. 

Die Verbindung zwischen den XJustiz-Daten und den zusammen mit ihnen übermittelten 

Dokumenten bildet das Element Sendungsdaten enthalten. Dieses enthält Informationen 

über den Inhalt, das Dateiformat und den Dateinamen der beigefügten Dokumente. 

b) Elektronische Signatur 

Dokumente, die im elektronischen Rechtsverkehr ausgetauscht werden, bedürfen in der 

Regel einer qualifizierten elektronischen Signatur. Rechtlich maßgeblich und deshalb signaturbedürftig 

sind nicht die XJustiz-Daten, sondern die zusammen mit diesen übermittelten 

Dokumente, also z.B. die Klageschrift, ein gerichtliches Urteil usw. XJustiz selbst deshalb 

keine Festlegungen hinsichtlich der elektronischen Signatur. 

c) Übertragungsweg, Verschlüsselung, Transportsignatur 

XJustiz wurde bewusst so konzipiert, dass die Übermittlung nicht an einen bestimmten Ü- 

bertragungsweg gebunden ist. Auch insoweit ergeben sich die wesentlichen Vorgaben aus 

den OT-Leit-ERV. 

III. 

Einzelheiten 

1. Dateinamen 

Für die Dateinamen der XML-Schema-Dateien wird folgendes Muster verwendet: 

xj_nnnn_[ww_]b*_v-v.xsd 



Hierbei bedeuten: 

▪ xj 

Ein konstantes Präfix zur Kennzeichnung aller XJustiz-Schemata. 

▪ nnnn 

Eine vierstellige Zahl, die als Hilfsmittel verwendet wird, um die alphanumerische Reihenfolge 

der Dateinamen möglichst weitgehend in Einklang zu bringen mit der inhaltlichen 

Reihenfolge. 

Hierzu wird folgendes System verwendet: 

Die erste und die zweite Stelle zeigen an, ob die Datei zum Grundmodul oder zu einer 

Facherweiterung gehört. Für das Grundmodul ist dabei die Ziffernfolge 00 reserviert, für 

Facherweiterungen die Ziffernfolgen 01 bis 99. 

Die dritte und die vierte Stelle sollen eine an inhaltlichen Kriterien orientierte Sortierung 

der zu einem Modul gehörigen Dateien ermöglichen. 

Beispiel: Das Schema für das Grundmodul erhält die Nummer 0000, die zum Grundmodul gehörigen 

Wertelisten die Nummern 0010, 0020, 0030 usw.; die Zehnerschritte sollen es ermöglichen, später hinzukommende 

Wertelisten, die inhaltlich mit vorhandenen Wertelisten zusammenhängen, in das bestehende 

Schema einzureihen. 

▪ ww 

Ein optionaler Zusatz für besondere Schema-Arten. 

Zur Zeit wird dieser Zusatz nur bei Wertelisten verwendet; diese erhalten das Kennzeichen 

"wl". 

▪ b* 

Eine schlagwortartige Bezeichnung des Inhalts 

▪ v-v 

Die Angabe der Haupt- und Unterversion. 

Beispiel: Für die Version 1.0.0 lautet der Zusatz 1-0, ebenso für künftige Versionen 

1.0.1, 1.0.2 usw. Der derzeitige Zusatz lautet 1-3 für die Version 1.3.0 (Stand Mai 2005) 

und Version 1.3.0 (Stand Dezember 2005) . 



2. Modellierungsstil 

Objekte in XML-Schemata können entweder lokal oder global definiert werden. Beide Modellierungsarten 

haben Vor- und Nachteile. In XJustiz wurde ein gemischter Ansatz gewählt, 

der sich in der Formel "lokale Elemente – globale Datentypen" zusammenfassen lässt. 

Global definierte Elemente sind in der Inhaltsstruktur als unmittelbare Kinder des Schema- 

Elements angeordnet. Solche Elemente können durch Refererenzierung in das Inhaltsmodell 

aller anderen Elemente eingebunden werden. Ein Design, das ausschließlich mit globalen 

Elementen arbeitet, wird häufig als Salamischeiben-Design bezeichnet. Viele XML- 

Editoren, die den XML-Code automatisch erzeugen, arbeiten mit dieser Technik. Der hauptsächliche 

Vorteil liegt in der mehrfachen Verwertbarkeit der Definitionen. Ein Nachteil besteht 

häufig darin, dass die Code-Struktur schnell unübersichtlich wird. 

Lokal definierte Elemente sind in die Deklaration eines anderen Objekts eingeschlossen. 

Solche Elemente können nur in ihrem jeweiligen Zusammenhang verwendet werden, können 

also nicht in das Inhaltsmodell anderer Elemente eingebunden werden. Ein Design, das 

ausschließlich mit lokalen Elementen arbeitet, wird häufig als Matroschka-Design bezeichnet. 

Ein Vorteil dieser Technik besteht darin, dass die Code-Struktur weitestgehend mit der 

fachlichen Anordnung der Daten übereinstimmt. Nachteilig ist, dass gleichartig strukturierte 

Elemente separat definiert werden müssen, was vor allem den Aufwand für die spätere 

Weiterentwickung und Pflege erhöht. 

Ein Mittelweg besteht darin, lokale Elemente zu verwenden, ergänzend aber globale Typen 

zu deklarieren, auf die bei der Deklaration der Elemente Bezug genommen werden kann. 

Ein solches typgestütztes Design wird häufig auch als Jalousie-Design bezeichnet. Es 

vereint die Vorteile der beiden übrigen Designmodelle, ohne dass gravierende Nachteile in 

Kauf genommen werden müssen. 

XJustiz orientiert sich im Wesentlichen am typgestützten Design. Globale Typen wurden 

allerdings nur dann definiert, wenn die betreffende Teilstruktur in gleicher Weise in mehreren 

Elementen vorkommt oder wenn zumindest damit zu rechnen ist, dass spätere Facherweiterungen 

Elemente gleicher Struktur aufweisen werden. 



Typisches Beispiel ist der Typ T_Geldbetrag: Das Grundmodul enthält an einigen Stellen 

Elemente, die einen Geldbetrag darstellen. Der global definierte Typ T_Geldbetrag stellt 

sicher, dass alle diese Elemente dieselbe Struktur aufweisen. Im Falle einer späteren Änderung 

oder Erweiterung des Datenmodells braucht nur die Typ-Definition geändert zu werden; 

in allen zugehörigen Elementen stehen die Änderungen dann ohne weiteres zur Verfügung. 

Sofern in späteren Fachmodulen weitere Elemente mit gleicher Funktion hinzukommen, 

sollte auch diesen der Typ T_Geldbetrag zugewiesen werden, damit die Einheitlichkeit 

der Datenstrukturen gewahrt bleibt. 

 

 

 

 

 

 

Abbildung 7: Definition des Datentyps T_Geldbetrag 

Elemente sind in XJustiz dagegen stets lokal definiert. Sie sind teilweise tief geschachtelt, 

um die fachlich vorgegebene Struktur der Daten möglichst originalgetreu im Inhaltsmodell 

wiederzugeben. 



Abbildung 8: Verschachtelung der Elemente 

3. Häufigkeiten (Kardinalitäten) 

a) minOccurs und maxOccurs 

Bei der Definition von Elementen in einem XML-Schema kann auch angegeben werden, 

wie oft ein Element mindestens vorkommen muss und wie oft es höchstens vorkommen 

darf. Hierzu dienen die Attribute minOccurs und maxOccurs. Beiden Attributen kann ein beliebiger 

ganzzahliger Wert oder der Wert unbounded zugewiesen werden. Typische sind für 

minOccurs die Werte 1 oder 0, für maxOccurs die Werte 1 oder unbounded. Der Standardwert 

beider Attribute ist 1. Er braucht nicht explizit zugewiesen zu werden. Enthält ein Element 

weder das eine noch das andere Attribut, bedeutet dies folglich, dass es genau einmal 

vorkommen darf und muss. 



In XJustiz werden viele Elemente mit minOccurs=“0“ eingesetzt. Dies ergibt sich aus der 

Zielsetzung von XJustiz: In aller Regel enthält ein XJustiz-Instanzdokument nur eine verhältnismäßig 

geringe Teilmenge der in Grund- und Fachmodulen vorgesehenen Elemente. 

Welche Elemente vorhanden sind und welche fehlen, hängt vom jeweiligen fachlichen Zusammenhang 

und vom Einzelfall ab. Allgemeine Regeln lassen sich dafür kaum bilden. Um 

die für diese Ausgangslage erforderliche Flexibilität zu erreichen, ist die Zahl der Pflicht- 

Elemente, also der Elemente mit maxOccurs="1", auf ein Minimum reduziert. 

b) Leere Elemente 

Daneben besteht die Möglichkeit, ein Element zwar als zwingend zu deklarieren (also minOccurs="1"), 

aber zuzulassen, dass es ohne Inhalt bleibt. Hierzu dienen das Attribut nillable="true" 

im XML-Schema und das Attribut xsi:nil=“true“ im zugehörigen Instanzdokument. 

Wird in der Deklaration eines Elements nillable="true" angegeben, werden Elemente ohne 

Inhalt auch dann geduldet, wenn dies mit dem Datentyp, dem das Element zugeordnet ist, 

an sich nicht vereinbar wäre. Von dieser Möglichkeit wurde in XJustiz bei Elementen 

Gebrauch gemacht, die zwar nicht in jedem Fall vorhanden sein müssen, die aber aus fachlichen 

Gründen erfahrungsgemäß häufig vorkommen. Diese Elemente müssen in jedem 

Instanzdokument vorkommen, dürfen aber über das Attribut xsi:nil=“true“ einen leeren Inhalt 

zugewiesen bekommen. Auf diese Weise wird einerseits gewährleistet, dass jedes Instanzdokument 

einen gewissen Mindestbestand an Elementen hat, andererseits verhindert, dass 

ein Datenaustausch daran scheitert, dass es zu einem bestimmten Element keinen Inhalt 

gibt. 

Das Attribut xsi:nil ist im XML-Schema-Namensraum für Instanzen, 

(http://www.w3.org/2001/XMLSchema-instance) definiert. Zu Referenzierungszwecken wird 

diesem Namensraum in der Regel das Präfix xsi: zugewiesen. Instanzdokumente, die das 

Attribut verwenden, müssen diesen Namensraum einbinden. Hierbei kann theoretisch jedes 

beliebige Präfix verwendet werden. Zur besseren Verständlichkeit empfiehlt es sich jedoch, 

generell das gebräuchliche Präfix xsi: zu verwenden. 


XJustiz Version 1.3 Technische Dokumentation 27 

Die Auswahl zwischen Elementen, die mit dem Attribut minOccurs="0" versehen werden, 

und solchen, bei denen minOccurs="0" und nillable="true" gesetzt ist, erfolgte aus praktischen 

Erfahrungen heraus und hat keinen tiefer gehenden fachlichen oder datentechnischen 

Hintergrund. 

Die Attribute nillable und xsi:nil erinnern an das Konzept der Nullwerte, wie es bei Datenbanksystemen 

gebräuchlich ist. Trotz dieser Ähnlichkeit gibt es aber einen entscheidenden 

Unterschied: In XML-Schema-Definitionen wird klar unterschieden zwischen einem nicht 

vorhandenen Element, einem nil-Element und einem Element mit leerem Inhalt. In Datenbanksystemen 

wird hingegen in der Regel sowohl das Nichtvorhandensein eines Elements 

als auch der Wert xsi:nil durch NULL gekennzeichnet. Eine Import- oder Export-Software, 

die XJustiz-Daten auf den Inhalt einer Datenbank abbildet, wird deshalb beim Import sowohl 

ein nicht vorhandenes Element als auch ein nil-Element in den Datenbankwert NULL umsetzen. 

Beim Export eines Feldes mit Inhalt NULL ist zu unterscheiden: Sofern das entsprechende 

Element auf XML-Seite optional ist (also minOccurs="0"), sollte es weggelassen 

werden. Ist es zwingend, muss es mit dem Attribut xsi:nil versehen werden. 

c) Leerstrings 

Bei Elementen vom Typ xs:string kann ein „leerer“ Feldinhalt auch auf andere Weise übermittelt 

werden: Die Definition dieses Datentyps lässt es zu, dass als xs:string-Wert auch 

eine Zeichenkette der Länge 0 übermittelt wird. Dadurch kann es vorkommen, dass selbst 

in Pflichtelementen (also Elementen, bei denen minOccurs nicht explizit definiert ist und 

deshalb den Wert 1 hat), die nicht als nillable deklariert sind, nur ein Leerstring übermittelt 

wird. 

 

 

 

 

 

Abbildung 9: Übermittlung eines Leerstrings in einem Pflichtfeld 



Aus Gründen der Kompatibilität zum XML-Standard wurde darauf verzichtet, in XJustiz weitergehende 

Regeln für den Inhalt von xs:string-Werten zu definieren. Sofern die Zieldatenbank 

für die betreffenden Felder keine Leerstrings zulässt, muss das Importprogramm deshalb 

eigene Prüfroutinen aufweisen, um solche Datensätze abzufangen. Generell empfiehlt 

es sich, überall dort, wo geprüft wird, ob ein Element den Wert xsi:nil hat, zugleich zu prüfen, 

ob das Element aus einem Leerstring besteht. 

4. Interne Referenzierung 

a) Ausgangspunkt 

Häufig kommt es vor, dass dieselbe Information an verschiedenen Stellen innerhalb desselben 

Instanzdokuments anzugeben ist. 

Typische Beispiele: 

▪ Ein Rechtsanwalt ist Absender eines Dokuments und zugleich Prozessbevollmächtigter 

eines Prozessbeteiligten. 

▪ Ein Prozessbeteiligter ist zugleich Beklagter und Geschäftsführer einer zusammen mit 

ihm verklagten Gesellschaft. 

Um in solchen Fällen Redundanzen zu vermeiden, enthält das Grundmodul an einigen Stellen 

Verweisungsmechanismen, die ähnlich funktionieren wie Schlüsselbeziehungen in 

einer relationalen Datenbank. Dadurch brauchen die Personendaten eines Beteiligten, auf 

den in einem Instanzdokument mehrfach Bezug genommen wird, in diesem Instanzdokument 

nur einmal aufgeführt zu werden, und zwar im Element Beteiligung. An allen anderen 

Stellen des Dokuments, an denen dieser Beteiligte in Erscheinung tritt, genügt dann ein 

Verweis auf das Beteiligungs-Element, das die vollständigen Daten enthält. 

In dem oben gebildeten Beispiel ermöglicht dies folgende Vorgehensweise: 

▪ Die Daten des Rechtsanwalts und der von ihm vertretenen Beteiligten werden als Elemente 

unter der Rubrik Beteiligung aufgeführt. Das Element Absender enthält dann lediglich 

einen Verweis auf das Beteiligten-Element des Rechtsanwalts. Für die Prozessvollmacht 

erfolgt die Referenzierung in anderer Richtung: Beim Anwalt wird vermerkt, 



dass er die Rolle des Prozessbevollmächtigten hat; in diesem Zusammenhang wird auf 

den (oder die) Beteiligten referenziert, die der Anwalt vertritt. 

▪ 

Der Beklagte, der zugleich Geschäftsführer einer mitverklagten Gesellschaft ist, erhält 

zwei Rollen zugewiesen: zum einen die eines Beklagten, zum anderen die des Geschäftsführers, 

und zwar mit einem Verweis auf die von ihm vertretene Gesellschaft. 

b) Eingesetzte Werkzeuge 

Um Referenzierungen in der beschriebenen Art zu ermöglichen und zugleich zu gewährleisten, 

dass die in einem Instanzdokument enthaltenen Verweise zu einem eindeutigen Ziel 

führen, werden in XJustiz die in XML-Schema vorgesehenen Hilfsmittel Schlüssel- 

Eigenschaft, Fremdschlüsselbedingung und Eindeutigkeits-Eigenschaft (Identity 

Constraints) verwendet. 

(1) Schlüssel-Eigenschaft 

XML-Schema ermöglicht es, eine Schlüssel-Eigenschaft zu definieren. Damit wird gewährleistet, 

dass in einer bestimmten Menge von Elementen eine bestimmte Kombination nur 

ein einziges Mal vorkommt. Zur Definition einer solchen Eigenschaft dient der Befehl 

xs:key. 

Der Schlüssel muss innerhalb des Elements definiert werden, welches eindeutig gehalten 

werden soll, und zwar am Ende der Element-Definition. Zur Kennzeichnung der Elemente, 

aus denen der eindeutige Schlüssel bestehen soll, werden XPath-Ausdrücke verwendet. 

Dabei wird mit xs:selector eine Menge von Elementen spezifiziert, auf die der Schlüssel 

angewendet wird. Mit xs:field wird angegeben, aus welchen (Unter-)Elementen der 

Schlüssel besteht 

In XJustiz speziell in den Fachmodulen sind drei solcher xs:key-Definitionen enthalten: 

▪ Schluessel_Beteiligter_Beteiligtennummer 

▪ Schluessel_Beteiligter_Rollennummer 

▪ Schluessel_Instanz 



(a) Schluessel_Beteiligter_Beteiligtennummer 

Dieser Schlüssel ist definiert durch die Beteiligtennummer eines Beteiligten. 

 

 

 

 

Abbildung 10: Schlüssel für Beteiligtennummer 

Hierüber besteht die Möglichkeit eine Person als Beteiligten über seine Beteiligtennummer 

zu referenzieren. 

(b) Schluessel_Beteiligter_Rollennummer 

Dieser Schlüssel ist definiert durch die Rollennummer eines Beteiligten. 

 

 

 

 

Abbildung 11: Schlüssel für Rollennummer 

In der Regel wird ein Beteiligter nur eine Rolle im Verfahren haben. Dann ist der Verweis 

auf die Rollennummer gleichbedeutend mit einem Verweis auf den betreffenden Beteiligten. 

Wenn ein Beteiligter mehrere Rollen hat, kann exakt angegeben werden, auf welche dieser 

Rolle(n) Bezug genommen werden soll. 

Beispiel: Ein Rechtsanwalt ist in einem Verfahren Prozessbevollmächtigter einer Partei und 

zugleich gesetzlicher Vertreter einer anderen Partei. Wenn dieser Anwalt ein bestimmtes 

Dokument nur im Namen einer dieser Parteien einreicht, kann dies im Element Absender 

dadurch gekennzeichnet werden, dass nur auf diese eine Rollennummer referenziert wird. 

Reicht derselbe Anwalt ein Dokument im Namen aller von ihm vertretenen Parteien ein, 



können mehrere Elemente Absender gebildet werden und darin auf alle vorhandenen Rollennummern 

des Rechtsanwalts verwiesen werden. 

(c) Schluessel_Instanz 

Dieser Schlüssel ermöglicht es, auf ein bestimmtes Gericht oder eine bestimmte Staatsanwaltschaft 

zu verweisen, die als Element in der Rubrik Verfahrensdaten/Instanzdaten angegeben 

ist. 

 

 

 

 

Abbildung 12: Schlüssel für Gerichte und Staatsanwaltschaften 

(2) Fremdschlüsselbedingung 

Ein Verweis auf einen der definierten Schlüssel erfolgt mit Hilfe der Anweisung xs:keyref. 

Bei der Definition eines xs:keyref-Elements wird mit Hilfe des Attributs refer der Name des 

Schlüssels angegeben, auf den verwiesen werden soll. Dadurch wird klargestellt, auf welches 

Element verwiesen wird. Mittels xs:selector und xs:path wird definiert, welche Elemente 

im verweisenden Objekt den Fremdschlüssel bilden. Hierdurch wird deutlich, von welchem 

Element der Referenzpunkt ausgeht. 

Ein Beispiel für einen solchen Verweis fand sich im Grundmodul bis zur Version 1.2.0 beispielsweise 

zur Definition des Teilnehmers eines Termins. 



 

 

 

 

Abbildung 13: Fremdschlüsselbedingung für Teilnehmer (bis Version 1.2) 

In dem aufgeführten Beispiel wurde definiert, dass der Inhalt des Elements 

Ref_Rollennummer in den Daten zu einem Teilnehmer an einem Termin übereinstimmen 

muss mit den entsprechenden Angaben eines im Instanzdokument unter der Rubrik Beteiligung 

aufgeführten Verfahrensbeteiligten. 

Um dies zu vermeiden, wurde in der Version 1.3.0 ein globaler Typ T_Ref_Rolle definiert, 

bei dem die Fremdschlüsselbedingung bereits in der Typ-Definition enthalten war. Diese 

Vorgehensweise wurde von einigen marktgängigen Parsern aber als unzulässig behandelt, 

weshalb es Probleme bei der Validierung von Instanzdokumenten gab. In der Version 1.3.1 

wurde die keyref-Definition innerhalb des Typs T_Ref_Rolle deshalb wieder entfernt. 

Stattdessen wurden die keyref-Definitionen durch die Verwendung von Platzhaltern in den 

xpath-Ausdrücken verallgemeinert Zwingende Konsequenz daraus war, dass die keyref- 

Definitionen aus dem Grunddatensatz in die Fachmodule ausgelagert werden mussten, weil 

erst in diesen die maßgebliche Baumstruktur vorhanden ist. 

Ab der XJustiz Version 1.3.1 bestehen die globalen Typdefinitionen weiterhin, um die 

Referenzierungen untereinander zu verdeutlichen. Die konkrete Schlüsselreferenzdefinition 

ist dem Root-Element des jeweiligen Fachmoduls zugeordnet und entspricht folgendem 

allgemeinem Schema: 



- xs:keyref nameRef_Rollennummertns:Schluessel_Beteiligter_Rollennummerxs:selector 

xpath.//*xs:field xpathtns:Ref_Rollennummerxs:keyref 

Diese keyref-Definition spricht alle unter dem Root-Element existierende Elemente mit 

Namen „Ref_Rollennummer“ an und legt über das Attribut refer die Verwendung des 

vordefinierten Schlüssels fest. Der im Selector angegebene XPath-Ausdruck (.//*) bezieht 

sich auf alle unter dem Root-Element definierten Elemente. Die Field-Definition bezieht sich 

nun konkret auf existierende Elemente namens Ref_Rollennummer. Durch das Zusammenspiel 

von Selector und Field verwenden nun alle existierenden Elemente mit Namen 

Ref_Rollennummer denselben Schlüssel (hier: Schluessel_Beteiligter_Rollennummer). 

Somit ist der Zusammenhang und die Notwendigkeit zwischen den global definierten 

Referenztypen (T_Ref_Rolle, T_Ref_Beteiligtennummer) und der Schlüsselreferenz- 

Definition (keyref) über das gleichlautenden Element Ref_Rollennummer hergestellt. 

Beispiel für die Verwendung: 

xs:element nametype 

Insgesamt enthält das Grundmodul zwei solcher globaler Typdefinitionen, die jeweils eine 

Element Ref_*** auf entsprechende Elemente vorweisen. 

• T_Ref_Rolle 

• T_Ref_Beteiligtennummer 

Insgesamt enthält das Grundmodul folgende über den globalen Typ definierte Beziehungen: 

(a) Beteiligung/Rolle/Referenz/Ref_Rollennummer 

Diese Fremdschlüsselbedingung fordert, dass sich die Angabe, auf welchen anderen Beteiligten 

sich eine Rolle bezieht, mit den entsprechenden Angaben eines im Instanzdokument 

aufgeführten (anderen) Beteiligten deckt. 



Beispiel: Wenn bei einem Rechtsanwalt angegeben ist, dass er der Prozessbevollmächtigte 

des Klägers ist, muss es einen anderen Beteiligten mit der in Bezug genommenen Rollennummer 

geben. 

xs:element nameReferenztypeT_Ref_RolleminOccurs0maxOccursunbounded 

Hier wird ein Bezug zu einer anderen Rolle angegeben. Beispielsweise handeln Rechtsanwälte 

in aller Regel als Prozessbevollmächtigte für einen anderen Beteiligten. Im vorliegenden 

Feld wird dann vermerkt, für welchen Beteiligten (ggf. auch in welcher Rolle) der 

Rechtsanwalt handelt. Für jede Rolle, auf die verwiesen wird, muss ein entsprechendes 

Element "Beteiligung/Rolle" vorhanden sein. Verwiesen wird auf die Rollennummer. 

(b) Termin/Terminsdaten/Teilnehmer/Ref_Rollennummer 

Diese Fremdschlüsselbedingung fordert, dass der Inhalt des Elements Ref_Rollennummer 

in der Auflistung der Beteiligten, die an einem Termin teilnehmen, übereinstimmen muss mit 

den entsprechenden Angaben eines im Instanzdokument unter der Rubrik Beteiligung aufgeführten 

Verfahrensbeteiligten. Verwendet wird diese Beziehung für Ladungen von 

Beteiligten zu einem Termin ist dadurch gegeben. 

 

(c) Verfahrensdaten/Instanzdaten/Instanzbehörde/Sonstige 

Dieses Element enthält einen Verweis auf eine Beteiligung (Behörde). Verwiesen wird auf 

den Wert der Rollennummer in "Beteiligung/Rolle". Für jeden Beteiligten, auf den verwiesen 

wird, muss ein entsprechendes Element "Beteiligung" vorhanden sein. Es werden sonstige 

Behörden referenziert. 

 



(d) Entscheidung/Zustellung/Zustellungsempfaenger 

Ein Zustellungsempfänger stellt ebenfalls eine Referenz auf eine Rollennummer einer beteiligten 

Person dar. 

 

(e) Entscheidung/Rechtskraft/Betroffener 

Die beteiligte Person, die von der Rechtskraft einer Entscheidung betroffen ist, kann über 

diese Beziehung referenziert werden. 

 

(f) Entscheidung/Entscheidungstenor/Betroffener 

Eine von der Entscheidung betroffene Person, die im Entscheidungstenor vorkommt, wird 

ebenfalls über ihre Rollennummer referenziert. 

 

(g) Referenz_Adresse 

Diese Fremdschlüsselbedingung ist dem Namensraum von XDOMEA zugeordnet und bezieht 

sich auf eine Schlüsseldefinition Schluessel_Adresse, die ebenfalls zu XDOMEA gehört. 

.Die Bedingung bezieht sich auf Elemente des importierten Namensraums von XDO- 

MEA. Aus diesem Grund ist sie dem Element XDOMEA in den Sendungsdaten zugeordnet. 

 

 

 

 

Abbildung 14: Fremdschlüsselbedingung für die Absender- und Empfängerangabe 



(h) Ref_Beteiligter_Instanz 

Diese Fremdschlüsselbedingung dient für Verweisungen von der Rollen_ID eines Beteiligten 

auf die entsprechende Instanznummer der Instanzdaten, in der der Beteiligte auftritt. 

Hiermit ist der Bezug des Beteiligten zur Instanz gegeben. Der Verweis geht von der 

Ref_Instanznummer der Beteiligung/Rolle/Rollen_ID aus. Verwendet wird hierzu die 

Schlüsseldefinition Schluessel_Instanz. 

 

(3) Eindeutigkeits-Eigenschaft 

Ähnliche Funktionen wie die Anweisung xs:key erfüllt die Anweisung xs:unique. Wie bei 

xs:key wird mit xs:unique festgelegt, dass eine bestimmte Kombination von Elementen eindeutige 

Inhalte enthalten muss. Der Unterschied besteht darin, dass ein mit xs:key 

spezifiziertes Element in jedem Fall vorkommen muss. Eine Spezifikation mit xs:unique 

lässt dagegen offen, ob ein davon betroffenes Element vorkommt oder nicht. Für den Fall, 

dass das betroffene Element vorkommt – und nur für diesen Fall – legt xs:unique fest, dass 

es eindeutig sein muss. 

Im Grundmodul gibt es eine xs:unique-Spezifikation: 

(a) Rollenbezeichnung und laufende Nummer 

Die Kombination aus Rollenbezeichnung und laufender Nummer eines Beteiligten muss 

eindeutig sein. Das heißt beispielsweise: Wenn es in einem Verfahren mehrere Kläger gibt, 

muss jedem von ihnen eine eindeutige laufende Nummer zugewiesen werden (typischerweise 

"Kläger 1", "Kläger 2" usw.). Gibt es in dem Verfahren nur einen Kläger, bedürfte zur 

Einhaltung der unique-Bedingung eigentlich keiner laufenden Nummer. Das Feld Nr ist aber 

als Pflichtfeld ausgestaltet, so dass im Ergebnis auch einer nur einmal vorkommenden Beteiligungsart 

eine Nummer zugeteilt werden muss. 



 

 

 

 

 

Abbildung 15: Eindeutigkeit der Rollenbezeichnung 

(b) Konsequenzen für die Erstellung der Instanzdokumente 

Bei der Erstellung von Instanzdokumenten müssen alle mit xs:key, xs:keyref und xs:unique 

definierten Regeln beachtet und eingehalten werden. Jede Software, die XJustiz- 

Instanzdokumente erzeugt, muss deshalb Routinen bereitstellen, die die Einhaltung dieser 

Regeln gewährleisten – sei es, indem Programmierwerkzeuge eingesetzt werden, die schon 

von Haus aus entsprechende Funktionen bieten, sei es, indem eigens solche Funktionen 

programmiert werden. 

5. Erweiterung und Einschränkung 

Die XML-Schema-Sprache erlaubt es, aus bereits definierten Typen durch Erweiterung oder 

Einschränkung neue abgeleitete Typen zu definieren. Hierzu dienen die Anweisungen 

xs:restriction und xs:extension. 

a) Erweiterung 

Die Anweisung xs:extension ermöglicht die Ableitung durch Erweiterung. Dabei werden 

neue Elemente oder Attribute zu einem bestehenden Inhaltsmodell aufgenommen. Durch 

xs:extension hinzugefügte Elemente werden an die Sequenz des eingeerbten Inhaltsmodells 

angehängt. 

b) Einschränkung 

Die Anweisung xs:restriction dient der Ableitung durch Einschränkung. Die Einschränkung 

kann beispielsweise darin bestehen, dass weniger Werte zugelassen werden als im Basistyp. 

Die Menge der durch den neuen Typ repräsentierten Werte ist mithin eine Untermenge 

der durch den Basistyp beschriebenen Werte. 



In XJustiz wird xs:restriction in den Wertelisten verwendet. Dort wird durch den Einsatz der 

einschränkenden Facette enumeration der Datentyp xs:string eingeschränkt, indem nur die 

in der Aufzählung (enumeration) enthaltenen Werte für gültig erklärt werden. 

Beispiel: Aus dem im Grundmodul definierten Basistyp WLT_String wird in der Werteliste für 

das Element Familienstand ein neuer Typ WL_Familienstand definiert, der nur noch einige 

wenige Stringwerte als Inhalt zulässt. 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Abbildung 16: Definition des Typs WL_Familienstand 

6. Versionierung 

Um ein Instanzdokument zuverlässig überprüfen zu können, muss klar sein, welches XML- 

Schema als Maßstab heranzuziehen ist. Dies kann zu Schwierigkeiten führen, sobald es 



von einem Schema mehrere Versionen gibt. Um dieses Problem zu lösen, wurde den 

XJustiz-Schemata folgendes Versionierungskonzept zu Grunde gelegt: 

a) Versionierung der Schema-Dateien 

Jede zu XJustiz gehörige XML-Schema-Datei erhält eine eigene Versionsnummer, die in 

einem dafür vorgesehenen Attribut version hinterlegt wird. 

(1) Bestandteile der Versionsnummer 

In der ersten Version von XJustiz hat die Versionsnummer bei allen Schema-Dateien den 

Wert 1.0.0. Im Rahmen der späteren Weiterentwicklung kann die Versionierung für jede 

einzelne Datei separat erfolgen. Derzeit steht das Versionsattribut des Grundmoduls auf 

1.3.1. 

 

Abbildung 17: Angabe der Versionsnummer im Kopf jeder Schema-Datei 

Die drei Stellen der Versionsnummer haben folgende Bedeutung: 

Die erste Stelle (1.x.x) identifiziert die Haupt-Version. Sie wird nur dann heraufgesetzt, 

wenn das Design von XJustiz grundlegende strukturelle Änderungen oder Erweiterungen 

erfährt. 

Die zweite Stelle (x.0.x) identifiziert die Unter-Version. Diese Stelle wird heraufgesetzt, 

wenn Änderungen an der Datenstruktur vorgenommen werden, die das grundlegende Design 

unberührt lassen. 

Die dritte Stelle (x.x.0) ist für die Beseitigung von Fehlern und die Vornahme kleinerer 

Änderungen ohne Auswirkungen auf die Datenstruktur vorgesehen. 

(2) Angabe der Versionsnummer im Dateinamen 

Die ersten beiden Stellen der Versionsnummer sind zugleich Bestandteil des Dateinamens 

jeder XML-Schema-Datei. 



Beispiel: Die Version 1.0.0 des Grundmoduls hat den Dateinamen 

xj_0000_grunddatensatz_1_0.xsd. Dieser Dateinamen wird bei Versionen mit derselben 

Datenstruktur (z.B. 1.0.1, 1.0.2 usw.) beibehalten. Eine spätere Version 1.1 erhält dagegen 

den Dateinamen xj_0000_grunddatensatz_1_1.xsd. Die derzeitige Bezeichnung lautet 

xj_0000_grunddatensatz_1_3.xsd. 

Eine Änderung des Dateinamens beim Grundmodul hat zur Folge, dass von allen Fachmodulen, 

die auf die neue Version zugreifen sollen, ebenfalls eine neue Version angelegt 

werden muss, in der die xs:include-Befehle an den neuen Dateinamen angepasst sind. 

(3) Verwaltung auf dem Server 

Alle Versionen von XJustiz sind im Internet dauerhaft unter der Adresse 

http://www.xjustiz.de abrufbar. Damit die Versionshistorie nachvollzogen werden kann und 

damit auch ältere Versionen auf Dauer zur Verfügung stehen, wird die Ablage auf dem Server 

wie folgt eingerichtet: 

Im Hauptverzeichnis ist der jeweils letzte Stand aller Unterversionen (1.0, 1.1 usw.) zu 

finden. 

Das Verzeichnis archiv enthält ergänzend ein vollständiges Archiv aller veröffentlichten 

Versionen einschließlich aller Fehlerbereinigungen. Für jede Unterversion (1.0, 1.1 usw.) 

existiert ein Verzeichnis. Dieses wiederum enthält für jede Fehlerbereinigungs-Version 

(1.0.0, 1.0.1, 1.0.2 usw.) ein separates Unterverzeichnis. 

Insgesamt ergibt sich damit folgende Ablagestruktur: 



Abbildung 18: Ablagestruktur auf dem öffentlich zugänglichen Server 

b) Wiedergabe der Versionsnummer in Instanzdokumenten 

In den Instanzdokumenten wird die Version der zu Grunde liegenden Schemata an mehreren 

Stellen und auf mehrere logischen Ebenen wiedergegeben: 

(1) Bezugnahme auf das Fachmodul 

Die wichtigste Angabe ist bereits im Kopf jedes Instanzdokuments im Attribut 

xsi:SchemaLocation enthalten. Wie bereits unter II.3 beschrieben, muss hier das Fachmodul 

angegeben werden, auf dem das Instanzdokument beruht. Über den hier angegebenen 

Dateinamen sind die Haupt- und die Unterversion eindeutig bestimmt, und zwar sowohl für 

das Fachmodul als auch für das von diesem eingebundene Grundmodul nebst Wertelisten. 

 

Abbildung 19: Verweis auf das Fachmodul im Instanzdokument 



(2) Versionsnummer des Elements Grunddaten 

In der Definition des Datentyps T_Grunddaten ist ein Attribut XJustizVersion vorgesehen, in 

welchem nochmals die ersten beiden Stellen der Versionsnummer angegeben werden. Ein 

Instanzdokument ist nur gültig, wenn es dieses Attribut aufweist und wenn dessen Inhalt mit 

dem in der Schema-Datei festgelegten Wert übereinstimmt. 

 

Abbildung 20: Versions-Attribut des Elements Grunddaten 

(3) Versionsnummer der Wertelisten 

Alle Datentypen, die eine abschließende Werteliste vorsehen (also alle Datentypen mit Präfix 

WL_, vgl. oben II.2.b)) enthalten ein zwingendes Attribut wl_version und ein optionales 

Attribut wl_fassung. 

(a) Attribut wl_version 

Das Attribut wl_version enthält die ersten beiden Stellen der Versionsnummer. Maßgeblich 

ist dabei nicht die Versionsnummer des Grundmoduls, sondern die Versionsnummer der 

Schema-Datei, in der die Werteliste definiert ist. Diese kann von der Versionsnummer des 

Grundmoduls abweichen. 

Jedes Instanzdokument muss dieses Attribut zwingend enthalten. Das Instanzdokument 

ist nur gültig, wenn der Inhalt des Attributs identisch ist mit dem in der Schema-Datei der 

Werteliste vorgegebenen Wert. 

Zivilsachen 

Abbildung 21: Versions- und Fassungs-Attribut in Wertelisten 



(b) Attribut wl_fassung 

Das Attribut wl_fassung enthält die dritte Stelle der Versionsnummer. Dieses Attribut ist optional. 

Ein Instanzdokument, das dieses Attribut nicht enthält oder hier eine Fassung angibt, die 

nicht existiert, wird vom XML-Parser deshalb nicht beanstandet. In der Praxis sollte dennoch 

stets die korrekte Ziffer angegeben werden. 

Die Unterscheidung zwischen wl_version und wl_fassung wurde gewählt, um bei der Verwendung 

von Wertelisten ein Restmaß an Flexibilität zu bewahren. Würde die Versionsnummer 

bis zur letzten Stelle fest vorgegeben, hieße dies, dass jede Ergänzung einer Werteliste 

– zum Beispiel das Einfügen eines neuen Staatennamens in die Werteliste für Staaten 

– alle Fachmodule, die auf diese Werteliste Bezug nehmen, ebenfalls angepasst werden 

müssten. Der hier gewählte Ansatz ermöglicht es dagegen, solche Einfügungen vorzunehmen, 

ohne dass eine neue XJustiz-(Unter-)Version erstellt werden muss, und dennoch 

stets die Information zu haben, welche Fassung einer Werteliste dem Instanzdokument zu 

Grunde liegt. 

7. Parser 

Zur Prüfung, ob ein Instanzdokument den Regeln des zugehörigen XML-Schemas entspricht, 

wird ein so genannter Parser eingesetzt. Solche Parser sind Standard-Produkte und 

werden von verschiedenen Herstellern am Markt angeboten. Bei der Entwicklung von 

XJustiz wurde hierzu mit unter das Produkt XML Spy, Version 2004 release 2 bzw. XML 

Spy Version 2005 rel. 3 eingesetzt. 



IV. Abbildungsverzeichnis: 

Abbildung 1a: Aufbau des Elements T_Grunddaten.............................................................. 8 

Abbildung 2b: Aufbau des Elements XDOMEA ..................................................................... 9 

Abbildung 3: Datentypen im Grundmodul............................................................................ 10 

Abbildung 4: Einbindung des Grundmoduls und der Wertelisten......................................... 13 

Abbildung 5: Aufbau des Basis-Fachmoduls ....................................................................... 14 

Abbildung 6: Aufbau des Fachmoduls Familie..................................................................... 15 

Abbildung 7: Definition des Datentyps T_Geldbetrag.......................................................... 24 

Abbildung 8: Verschachtelung der Elemente....................................................................... 25 

Abbildung 9: Übermittlung eines Leerstrings in einem Pflichtfeld ........................................ 27 

Abbildung 10: Schlüssel für Beteiligtennummer .................................................................. 30 

Abbildung 11: Schlüssel für Rollennummer......................................................................... 30 

Abbildung 12: Schlüssel für Gerichte und Staatsanwaltschaften......................................... 31 

Abbildung 13: Fremdschlüsselbedingung für Teilnehmer (bis Version 1.2)......................... 32 

Abbildung 14: Fremdschlüsselbedingung für die Absender- und Empfängerangabe .......... 36 

Abbildung 15: Eindeutigkeit der Rollenbezeichnung............................................................ 37 

Abbildung 16: Definition des Typs WL_Familienstand......................................................... 38 

Abbildung 17: Angabe der Versionsnummer im Kopf jeder Schema-Datei ......................... 39 

Abbildung 18: Ablagestruktur auf dem öffentlich zugänglichen Server................................ 41 

Abbildung 19: Verweis auf das Fachmodul im Instanzdokument......................................... 41 

Abbildung 20: Versions-Attribut des Elements Grunddaten................................................. 42 

Abbildung 21: Versions- und Fassungs-Attribut in Wertelisten............................................ 42

xjustiz_techdok_2005-12-27_v131.pdf - OSCI

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?