Technische Dokumentation zu XJustiz Version 1.3.1

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

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

XJustiz Version 1.3 Technische Dokumentation 3 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:

XJustiz Version 1.3 Technische Dokumentation 4 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.

XJustiz Version 1.3 Technische Dokumentation 5 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.

XJustiz Version 1.3 Technische Dokumentation 6 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

XJustiz Version 1.3 Technische Dokumentation 7 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:

XJustiz Version 1.3 Technische Dokumentation 8 Abbildung 1a: Aufbau des Elements T_Grunddaten

XJustiz Version 1.3 Technische Dokumentation 9 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.

XJustiz Version 1.3 Technische Dokumentation 10 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.

XJustiz Version 1.3 Technische Dokumentation 11 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:

XJustiz Version 1.3 Technische Dokumentation 13 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:

XJustiz Version 1.3 Technische Dokumentation 14 (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.

XJustiz Version 1.3 Technische Dokumentation 15 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

XJustiz Version 1.3 Technische Dokumentation 16 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.

XJustiz Version 1.3 Technische Dokumentation 17 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: <Staat xsi:type="wl_staaten" wl_version="1.2" 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 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.

XJustiz Version 1.3 Technische Dokumentation 18 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"

XJustiz Version 1.3 Technische Dokumentation 19 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

XJustiz Version 1.3 Technische Dokumentation 20 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

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

XJustiz Version 1.3 Technische Dokumentation 22 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).

XJustiz Version 1.3 Technische Dokumentation 23 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.

XJustiz Version 1.3 Technische Dokumentation 24 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. <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 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.

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

XJustiz Version 1.3 Technische Dokumentation 26 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. <Natuerliche_Person> <Voller_Name> <Nachname></Nachname> </Voller_Name> <Natuerliche_Person> Abbildung 9: Übermittlung eines Leerstrings in einem Pflichtfeld

XJustiz Version 1.3 Technische Dokumentation 28 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,

XJustiz Version 1.3 Technische Dokumentation 29 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

XJustiz Version 1.3 Technische Dokumentation 30 (a) Schluessel_Beteiligter_Beteiligtennummer Dieser Schlüssel ist definiert durch die Beteiligtennummer eines Beteiligten. <xs:key name="schluessel_beteiligter_beteiligtennummer"> <xs:selector xpath="*/tns:verfahrensdaten/tns:beteiligung/tns:beteiligter" /> <xs:field xpath=" tns:beteiligtennummer" /> </xs:key> 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. <xs:key name="schluessel_beteiligter_rollennummer"> <xs:selector xpath="*/tns:verfahrensdaten/tns:beteiligung/tns:rolle" /> <xs:field xpath=" tns:rollennummer" /> </xs:key> 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,

XJustiz Version 1.3 Technische Dokumentation 31 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. <xs:key name="schluessel_instanz"> <xs:selector xpath="*/tns:verfahrensdaten/ tns:instanzdaten/ " /> <xs:field xpath="tns:instanznummer"/> </xs:key> 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.

XJustiz Version 1.3 Technische Dokumentation 32 <xs:keyref name="ref_termin_beteiligter_rolle" refer= "Schluessel_Beteiligter_Rollennummer"> <xs:selector xpath = "tns:verfahrensdaten/tns:termin/tns:terminsdaten/tns:teilnehmer"/> <xs:field xpath="tns:ref_rollennummer"/> </xs:keyref> 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:

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

XJustiz Version 1.3 Technische Dokumentation 34 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. <xs:element name="teilnehmer" type = T_Ref_Rolle nillable="true" maxoccurs="unbounded"> (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. <xs:element name="sonstige" type="t_ref_rolle">

XJustiz Version 1.3 Technische Dokumentation 35 (d) Entscheidung/Zustellung/Zustellungsempfaenger Ein Zustellungsempfänger stellt ebenfalls eine Referenz auf eine Rollennummer einer beteiligten Person dar. <xs:element name="zustellungsempfaenger" type="t_ref_rolle"> (e) Entscheidung/Rechtskraft/Betroffener Die beteiligte Person, die von der Rechtskraft einer Entscheidung betroffen ist, kann über diese Beziehung referenziert werden. <xs:element name="betroffener" type="t_ref_rolle" minoccurs="0" maxoccurs="unbounded"/> (f) Entscheidung/Entscheidungstenor/Betroffener Eine von der Entscheidung betroffene Person, die im Entscheidungstenor vorkommt, wird ebenfalls über ihre Rollennummer referenziert. <xs:element name="betroffener" type="t_ref_rolle" minoccurs="0" maxoccurs="unbounded"> (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. <xs:keyref name="referenz_adresse " refer="xdo:schluessel_adresse "> <xs:selector xpath="xdo:xdomea_daten/*/xdo:adress_informationen/*"/> <xs:field xpath="xdo:referenz"/> </xs:keyref> Abbildung 14: Fremdschlüsselbedingung für die Absender- und Empfängerangabe