Technische Dokumentation zu XJustiz Version 1.0

Transkript

1 15. Oktober 2003 Arbeitsgruppe IT-Standards in der Justiz Technische Dokumentation zu XJustiz Version 1.0 I. Einleitung Zielsetzung Grundzüge des Lösungsansatzes Bestandteile von XJustiz... 4 II. Aufbau und Inhalt der XML-Schema-Dateien Namensraum Grundmodul, Wertelisten und Fachmodule... 5 a) Grundmodul... 6 b) Wertelisten... 8 c) Fachmodule d) Include-Technik Bezugnahme auf die Schemata in Instanzdokumenten Statisches Datenmodell Bewusst ausgeklammerte Aspekte a) Dokumente und Meta-Informationen b) Elektronische Signatur c) Übertragungsweg, Verschlüsselung, Transportsignatur III. Einzelheiten Dateinamen Modellierungsstil Häufigkeiten (Kardinalitäten) a) minoccurs und maxoccurs b) Leere Elemente Interne Referenzierung a) Ausgangspunkt b) Eingesetzte Werkzeuge c) Konsequenzen für die Erstellung der Instanzdokumente Erweiterung und Einschränkung a) Erweiterung b) Einschränkung Versionierung a) Versionierung der Schema-Dateien b) Wiedergabe der Versionsnummer in Instanzdokumenten... 34

2 XJustiz Version 1.1 Technische Dokumentation 2 Versionsangaben Version 1.1 Stand vom Bearbeitet von I. Bauer, K. Bacher Status Freigegeben Freigegeben AG-IT am Freigegeben BLK am Änderungshistorie Datum Was wurde geändert Wer hat geändert Neuerstellung Irina Bauer Redaktionelle Überarbeitung Klaus Bacher Angaben zu Version und Änderungshistorie eingefügt Klaus Bacher Änderungen auf Vorschlag NRW eingefügt Klaus Bacher Freigabe BLK, V1.1 erstellt J. Ehrmann

3 XJustiz Version 1.1 Technische Dokumentation 3 I. Einleitung 1. Zielsetzung Das Datenformat XJustiz soll den Austausch von verfahrensrelevanten Daten zwischen Gerichten, Staatsanwaltschaften und Verfahrensbeteiligten nach einem bundesweit einheitlichen Standard ermöglichen. Ziel ist es, dass alle anfallenden Daten möglichst nur einmal manuell erfasst werden müssen und dann von allen anderen Verfahrensbeteiligten elektronisch übernommen und eingelesen werden können. Dabei sollen möglichst alle Zielsysteme bei Gerichten, Staatsanwaltschaften, Anwälten, Steuerberatern usw. unterstützt werden. Nicht von der Zielsetzung umfasst ist hingegen eine vollautomatische Datenübernahme. Die übermittelten XJustiz-Daten sollen erst dann endgültig in die Datenbank des Empfängers Eingang finden, wenn sie von einem Bearbeiter geprüft und freigegeben worden sind. Erspart werden soll nur der Aufwand für das Eintippen (oder Einscannen und OCR-Bearbeiten) der Daten, nicht der Erfassungsvorgang insgesamt. Erst recht soll XJustiz nicht dazu dienen, beim Empfänger automatisierte Bearbeitungsvorgänge mit Außenwirkung anzustoßen. Ziel von XJustiz im elektronischen Rechtsverkehr ist der erleichterte und problemlose Datenaustausch zwischen Verfahrensbeteiligten, wie Gerichten, Staatsanwaltschaften, Rechtsanwälten usw. Die für XJustiz gewählte Auszeichnungssprache XML kann das Konzept des Datenaustausches umsetzen. 2. Grundzüge des Lösungsansatzes XJustiz bedient sich der Seitenbeschreibungssprache 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.

4 XJustiz Version 1.1 Technische Dokumentation 4 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. 3. Bestandteile von XJustiz Die Definition der XJustiz-Datenstrukturen ist derzeit in folgenden XML-Schema- Dateien hinterlegt: Grundmodul (xj_0000_grunddatensatz_1_0.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_0.xsd xj_0020_wl_gerichte_1_0.xsd xj_0030_wl_rechtsform_1_0.xsd xj_0040_wl_rollenbezeichnung_1_0.xsd xj_0050_wl_staaten_1_0.xsd xj_0060_wl_telekommunikation1_0.xsd Basis-Fachmodul (xj_0100_basis_1_0.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.

5 XJustiz Version 1.1 Technische Dokumentation 5 Fachmodul Familie (xj_0200_familie_1_0.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. 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 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 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 elementformdefault 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 Damit sind alle zu XJustiz gehörigen Objekte einem einheitlichen Namensraum zugeordnet. Dies

6 XJustiz Version 1.1 Technische Dokumentation 6 vereinfacht die Erweiterung durch Vererbung von Typen und die Anbindung von externen Listen. 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 zusam-

7 XJustiz Version 1.1 Technische Dokumentation 7 mengefasst 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: Sachgebiet Verfahrensnummer Instanzenzug Beteiligung Termin Das Unterelement Sendungsdaten definiert Meta-Informationen, für den einzelnen Übermittlungsvorgang. Es enthält seinerseits folgende Unterelemente: Sendungspriorität Bemerkung Absenderkennung Eingangsbestätigungswunsch Dokument Der vorstehend beschriebene Grundaufbau ist in nachfolgendem Schaubild nochmals zusammengefasst:

8 XJustiz Version 1.1 Technische Dokumentation 8 Abbildung 1: Aufbau des Elements T_Grunddaten 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:

9 XJustiz Version 1.1 Technische Dokumentation 9 Abbildung 2: 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_0.xsd zusammengefasst. Im einzelnen gehören zum Grundmodul folgende Wertelisten-Dateien: xj_0010_wl_allgemein_1_0.xsd xj_0020_wl_gerichte_1_0.xsd xj_0030_wl_rechtsform_1_0.xsd xj_0040_wl_rollenbezeichnung_1_0.xsd xj_0050_wl_staaten_1_0.xsd xj_0060_wl_telekommunikation_1_0.xsd

10 XJustiz Version 1.1 Technische Dokumentation 10 Die Datei wl_allgemein_1_0.xsd enthält Wertelisten für folgende Elemente: Sachgebiet Familienstand Anschriftstyp Geschlecht Dateiformat 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 Werteliste 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 Schlüsselreferenzen 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.

11 XJustiz Version 1.1 Technische Dokumentation 11 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 verweisen über include-befehle auf das Grundmodul und die zu diesem gehörigen Wertelisten. 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:

12 XJustiz Version 1.1 Technische Dokumentation 12 Abbildung 3: 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.

13 XJustiz Version 1.1 Technische Dokumentation 13 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 4: 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 Basis-Fachmoduls ist in der nachfolgenden Grafik dargestellt.

14 XJustiz Version 1.1 Technische Dokumentation 14 Abbildung 5: Aufbau des Fachmoduls Familie (4) Anbindung der Wertelisten Die für bestimmte Elemente definierten Wertelisten werden im Fachdatensatz durch einen Verweis auf die betreffenden Wertelisten-Dateien zur Verfügung gestellt. Innerhalb des Fachdatensatzes besteht die Möglichkeit, diese Wertelisten nochmals einzuschränken oder zu erweitern, um sie den Erfordernissen des jeweiligen Fachgebiets anzupassen. Im Fachmodul Familie wurde von dieser Möglichkeit beispielsweise für die Werteliste Gegenstandsbezeichnung Gebrauch gemacht. Um bei der Verwendung von Wertelisten ein Mindestmaß an Flexibilität zu bewahren, enthält das Grundmodul keine Bindung an einen Wertelistentyp. Elemente, für die die Verwendung von Wertelisten in Betracht kommt, weisen stattdesen 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 verwendet werden, muss dies im Instanzdokument durch Verwendung des Attributs xsi:type kenntlich gemacht werden.

15 XJustiz Version 1.1 Technische Dokumentation 15 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 Werteliste 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: <Staat>Irgendein neu gegründeter Staat</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:

16 XJustiz Version 1.1 Technische Dokumentation 16 <Staat xsi:type="wl_staaten" wl_version="1.0" wl_fassung="0"> DE </Staat> 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 Sowohl das Grundmodul als auch die Wertelisten werden mit Hilfe der Anweisung xs:include in die Fachmodule eingebunden. 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 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 Module in den einheitlichen Namensraum zu integrieren und die Anbindung an andere Module über xs:include zu realisieren. 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.

17 XJustiz Version 1.1 Technische Dokumentation 17 Als Wert enthält es Paare aus einem Namensraum ( 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 den Verweis auf das Fachmodul und die darin enthaltenen xs:include-anweisungen 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 Änderungs- oder 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

18 XJustiz Version 1.1 Technische Dokumentation 18 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 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.

19 XJustiz Version 1.1 Technische Dokumentation 19 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 konstanter 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 Sor-

20 XJustiz Version 1.1 Technische Dokumentation 20 tierung 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 lautet der Zusatz 1-0, ebenso für künftige Versionen 1.0.1, usw. Für eine künftige Version lautet der Zusatz 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.

21 XJustiz Version 1.1 Technische Dokumentation 21 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.

22 XJustiz Version 1.1 Technische Dokumentation 22 <xs:complextype name="t_geldbetrag"> <xs:sequence> <xs:element name="zahl" type="xs:double" /> <xs:element name="waehrung" type="xs:string" default="eur"/> </xs:sequence> </xs:complextype> Abbildung 6: 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.

23 XJustiz Version 1.1 Technische Dokumentation 23 Abbildung 7: 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.

24 XJustiz Version 1.1 Technische Dokumentation 24 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, ( 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.

25 XJustiz Version 1.1 Technische Dokumentation 25 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 des 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. 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

26 XJustiz Version 1.1 Technische Dokumentation 26 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 den 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 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.

27 XJustiz Version 1.1 Technische Dokumentation 27 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 Im Grundmodul sind zwei solcher xs:key-definitionen enthalten: Schluessel_Beteiligter_Rollennummer Schluessel_Gericht (a) Schluessel_Beteiligter_Rollennummer Dieser Schlüssel ist definiert durch die Rollennummer eines Beteiligten. <xs:key name="schluessel_beteiligter_rollennummer"> <xs:selector xpath="tns:verfahrensdaten/tns:beteiligung/tns:rolle" /> <xs:field xpath=" tns:rollennummer" /> </xs:key> Abbildung 8: Schlüssel für Beteiligte und Rolle 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.

28 XJustiz Version 1.1 Technische Dokumentation 28 (b) Schluessel_Gericht Dieser Schlüssel ermöglicht es, auf ein bestimmtes Gericht oder eine bestimmte Staatsanwaltschaft zu verweisen, die als Element in der Rubrik Verfahrensdaten/Instanzenzug angegeben ist. <xs:key name="schluessel_gericht"> <xs:selector xpath="tns:verfahrensdaten/ tns:instanzenzug/tns:instanzdaten/ tns:gericht " /> <xs:field xpath="tns:gerichtskennzahl"/> </xs:key> Abbildung 9: 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. Mittels xs:selector und xs:path wird definiert, welche Elemente im verweisenden Objekt den Fremdschlüssel bilden. Ein Beispiel für einen solchen Verweis findet sich im Grundmodul beispielsweise zur Definition der Absender-Angabe: <xs:keyref name="ref_absender_beteiligter_rolle" refer="schluessel_beteiligter_rollennummer"> <xs:selector xpath="tns:sendungsdaten/ tns:dokument/tns:absender"/> <xs:field xpath="tns:ref_rollennummer" /> </xs:keyref> Abbildung 10: Fremdschlüsselbedingung für die Absenderangabe

29 XJustiz Version 1.1 Technische Dokumentation 29 In dem aufgeführten Beispiel wird definiert, dass der Inhalt des Elements Ref_Rollennummer in den Absenderangaben zu einem Dokument übereinstimmen muss mit den entsprechenden Angaben eines im Instanzdokument unter der Rubrik Beteiligung aufgeführten Verfahrensbeteiligten. Insgesamt enthält das Grundmodul sechs xs:keyref-definitionen: (a) Ref_Beteiligter_Rolle_Beteiligter 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:keyref name="ref_beteiligter_rolle_beteiligter" refer="schluessel_beteiligter_rollennummer"> Abbildung 11: Fremdschlüsselbedingung für Beziehungen zwischen einzelnen Beteiligten (b) Ref_Absender_Beteiligter_Rolle Diese Fremdschlüsselbedingung wurde bereits oben erläutert. (c) Ref_Absender_Gericht Diese Fremdschlüsselbedingung fordert, dass der Inhalt des Elements Ref_Gerichtskennzahl in den Absenderangaben zu einem Dokument übereinstimmen muss mit der entsprechenden Angabe eines im Instanzdokument unter der Rubrik Instanzdaten aufgeführten Gerichts.

30 XJustiz Version 1.1 Technische Dokumentation 30 <xs:keyref name="ref_absender_gericht" refer="schluessel_gericht"> <xs:selector xpath="tns:sendungsdaten/tns:dokument/tns:absender"/> <xs:field xpath= tns:ref_gerichtskennzahl" /> </xs:keyref> Abbildung 12: Fremdschlüsselbedingung für die Absenderangabe von Gerichten und Staatsanwaltschaften (d) Ref_Empfaenger_Beteiligter_Rolle Diese Fremdschlüsselbedingung hat dieselbe Struktur wie die bereits erläuterte Ref_Absender_Beteiligter_Rolle. Der Fremdschlüssel setzt sich hier aus den Angaben zum Empfänger eines Dokuments zusammen. <xs:keyref name="ref_empfaenger_beteiligter_rolle" refer="schluessel_beteiligter_rollennummer"> <xs:selector xpath="tns:sendungsdaten/tns:dokument/ tns:empfaenger"/> <xs:field xpath="/tns:ref_rollennummer" /> </xs:keyref> Abbildung 13: Fremdschlüsselbedingung für die Empfängerangabe (e) Ref_Empfaenger_Gericht Diese Fremdschlüsselbedingung hat dieselbe Struktur wie die bereits erläuterte Ref_Absender_Gericht. Der Fremdschlüssel setzt sich hier aus den Angaben zu einem als Empfänger eines Dokuments angegebenen Gericht zusammen. <xs:keyref name="ref_empfaenger_gericht" refer="schluessel_gericht"> <xs:selector xpath="tns:sendungsdaten/tns:dokument/ tns:empfaenger"/> <xs:field xpath="tns:ref_gerichtskennzahl" /> </xs:keyref> Abbildung 14: Fremdschlüsselbedingung für die Empfängerangabe von Gerichten und Staatsanwaltschaften

31 XJustiz Version 1.1 Technische Dokumentation 31 (f) Ref_Termin_Beteiligter_Rolle 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. <xs:keyref name="ref_termin_beteiligter_rolle" refer="schluessel_beteiligter_rollennummer"> Abbildung 15: Fremdschlüsselbedingung für Ladung von Beteiligten zu einem Termin (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 Inhalten 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 zwei xs:unique-spezifikationen: (a) Beteiligtennummer Optional kann das Gericht eine eindeutige Beteiligten-ID bekanntgeben. In der Regel ist dies nicht erforderlich, weil die Funktion einer solchen ID schon durch das Element Rollennummer erfüllt wird. Deshalb ist das Element Beteiligten-ID optional. Wenn es verwendet wird, sorgt die Eindeutigkeits-Eigenschaft dafür, dass jede Beteiligtennummer nur einmal im Instanzdokument vorkommt.

32 XJustiz Version 1.1 Technische Dokumentation 32 <xs:unique name="eindeutigkeit_beteiligtennummer"> <xs:selector xpath="tns:verfahrensdaten/tns:beteiligung/ tns:beteiligter"/> <xs:field xpath="tns:beteiligtennummer"/> </xs:unique> Abbildung 16: Eindeutigkeit der Beteiligtennummer (b) 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 hingegen nur einen Kläger, bedarf es keiner laufenden Nummer; die unique-bedingung greift dann nicht. <xs:unique name="eindeutigkeit_rollenbezeichnung_nummer"> <xs:selector xpath="tns:verfahrensdaten/tns:beteiligung/tns:rolle" /> <xs:field xpath="tns:rollenbezeichnung/tns:bezeichnung" /> <xs:field xpath="tns:nr" /> </xs:unique > Abbildung 17: Eindeutigkeit der Rollenbezeichnung c) 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.

33 XJustiz Version 1.1 Technische Dokumentation 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.

34 XJustiz Version 1.1 Technische Dokumentation 34 <xs:complextype name="wl_familienstand"> <xs:simplecontent> <xs:restriction base="wlt_string"> <xs:enumeration value="ledig" /> <xs:enumeration value="verheiratet" /> <xs:enumeration value="verpartnert" /> <xs:enumeration value="verwitwet" /> <xs:enumeration value="geschieden" /> <xs:enumeration value="partnerschaft aufgelöst" /> <xs:enumeration value="unbekannt" /> <xs:attribute name="wl_version" type="xs:string" use="required" fixed="1.0" /> <xs:attribute name="wl_fassung" type="xs:string" use="optional" default="0" /> </xs:restriction> </xs:simplecontent> </xs:complextype> Abbildung 18: 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.

35 XJustiz Version 1.1 Technische Dokumentation 35 (1) Bestandteile der Versionsnummer In der ersten Version von XJustiz hat die Versionsnummer bei allen Schema-Dateien den Wert Im Rahmen der späteren Weiterentwicklung kann die Versionierung für jede einzelne Datei separat erfolgen. <xs:schema... version="1.0.0"...> Abbildung 19: 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 des Grundmoduls hat den Dateinamen xj_0000_grunddatensatz_1_0.xsd. Dieser Dateinamen wird bei Versionen mit derselben Datenstruktur (z.b , usw.) beibehalten. Eine spätere Version 1.1 erhält dagegen den Dateinamen xj_0000_grunddatensatz_1_1.xsd. Eine Änderung des Dateinamens beim Grundmodul hat zur Folge, dass von allen Fachmodulen und Wertelisten, die auf die neue Version zugreifen sollen, ebenfalls