Modularisierung des XJustiz-Standards
Mit der Version 4.0.0 erweitert XJustiz ab dem 30. April 2026 den etablierten Release-Zyklus. Zwischen den etablierten, jährlichen Major Releases können Feature Updates veröffentlicht werden. Feature Updates betreffen ausschließlich die Ergänzung oder Änderung von Fachmodulen.
Zusammenfassung
Das Ziel dieser Umstellung ist eine deutliche Erhöhung der Flexibilität und Agilität beim Einsatz von XJustiz. Durch die Entkopplung von Grund- und Fachmodulen können fachspezifische Anforderungen schneller umgesetzt werden, ohne auf das nächste Major Release warten zu müssen.
Künftig wird zwischen zwei Arten von Veröffentlichungen unterschieden:
Major Releases
X.0.0
Major Releases erscheinen weiterhin jährlich zum 30. April und können Änderungen des Grundmoduls und/oder der Fachmodule enthalten. Sie werden am 30. April des Folgejahres gültig.
Feature Updates
4.X.0
Feature Updates enthalten nur Ergänzungen und/oder Änderungen von Fachmodulen und werden veröffentlicht, wenn alle Mitglieder des jeweiligen Anwenderkreises an den Abstimmungen beteiligt waren und der Veröffentlichung zugestimmt haben. Der etablierte Change-Request-Prozess (CR-Prozess) ist auch für Feature Updates vollständig zu durchlaufen. Ein Feature Update ist frühestens gültig, wenn das zugehörige Major Release gültig ist. Die Kommunikationspartner können hiervon abweichend abstimmen, Feature Updates schon vor dem Beginn der Gültigkeit einzusetzen.
Mit der Modularisierung des XJustiz-Standards wird ein neues Versionierungsmodell eingeführt:
- Major Release (Schema
X.0.0): Versionssprung 1. Stelle (z.B.4.0.0). - Feature Update (Schema z.B.
4.X.0): Versionssprung: 2. Stelle (z.B.4.1.0).
Das neue Versionsmodel beginnt mit der Version 4.0, die der XJustiz-Version 3.6.2 folgt.
Zudem ist das Attribut xjustizVersion im Nachrichtenkopf ab Version XJustiz 4.0 nicht mehr als fixed-Wert modelliert, sondern muss einem Pattern („4.x.y“) genügen. So kann beim Empfänger entschieden werden, ob gegen ein Major-Release oder ein Feature Update validiert werden soll.
Auswirkung
Die Einführung der Modularisierung stellt keine strukturelle Neuausrichtung dar, sondern eine formale Klarstellung der bereits bestehenden Architektur des XJustiz-Standards, die die strikte Trennung von Grundmodul und Fachmodulen bereits von Anfang an vorsieht.
Da sowohl Major Release als auch Feature Updates jeweils als vollständige Version des Standards bereitgestellt werden, sind weder bei den Erstellern noch bei den Empfängern von XJustiz-Nachrichten Anpassungen erforderlich. Durch den Verzicht auf den fixed-Wert bei der Angabe der XJustiz-Version kann auch die Validierung flexibel gestaltet werden.
Für die XSD-Validierung von XJustiz-Nachrichten ist der tatsächlich referenzierte Schema-Stand ausschlaggebend. Bei unveränderten Fachmodulen bleibt Validierung über Major Release und Feature Update hinweg möglich. Bei geänderten Fachmodulen ist dagegen i.d.R. der neue Schema-Stand des Feature Updates für die Validierung erforderlich.
Die technische Validierung per XSD folgt damit konsistent der fachlichen Betroffenheit des jeweiligen Moduls.
Nachfolgende Matrix gibt einen Überblick zu den verschiedenen Validierungsszenarien. Weitere Einzelheiten zur Validierung sind unter Ziffer 5 aufgeführt.
Major Release
Regulär validierbar, da derselbe Schema-Stand verwendet wird.
weiterhin validierbar, weil sich für dieses Modul die referenzierte XSD nicht geändert hat.
validierbar nur dann, wenn die Nachricht auch dem neue Feature-Update-Schema entspricht (wenn z.B. nur optinale Elemente ergänzt wurden, die in der Nachricht nicht verwendet werden) oder der Empfänger das Major Release zusätzlich noch auflösen kann.
Feature Update
weiterhin validierbar, weil kein neuer modulbezogener Schema-Stand referenziert wird.
nicht XSD-validierbar, weil der Empfänger nur die Major-Release-Schemata kennt und die neue XSD-Datei nicht auflösen kann.
Regulär validierbar, weil beide Seiten denselben neuen Schema-Stand des Feature Updates nutzen.
Entkopplung der XJustiz-Version von der Grunddatensatz-Version
Bisher entsprach die Nummer der XJustiz-Version immer auch der Nummer der Version des Grunddatensatzes.
Diese Gleichsetzung war historisch praktikabel, da Hauptreleases synchron erfolgten und keine eigenständige Release-Kommunikation auf Systemebene erforderlich war.
Mit der Einführung von Feature-Updates einzelner Fachmodule kann nun eine Divergenz zwischen Version des Grunddatensatzes und XJustiz-Gesamtversion entstehen. Die bisherige Gleichsetzung ist daher nicht mehr sachgerecht. Eine automatische Erhöhung der Grunddatensatz-Version auch bei Feature-Updates würde:
- eine inhaltlich nicht vorhandene Änderung suggerieren
- technische Inkompatibilitäten vortäuschen
- unnötige Migrations- und Prüfprozesse auslösen
- der tatsächlichen Architektur widersprechen
Die bisherige implizite Kopplung zwischen XJustiz-Version und Grunddatensatz-Version wird daher wie folgt aufgelöst:
- XJustiz-Version = Versionsnummer des Major Releases oder Feature Updates
- Komponentenversionen
- Grunddatensatz (eigene Versionslinie, Änderung nur im Hauptrelease)
- Fachmodule (eigene Versionslinien)
Beispiel
| XJustizVersion | Grunddatensatz | Fachmodul A | Fachmodul B | Art |
|---|---|---|---|---|
| 4.0.0 | 4.0.0 | 3.5 | 3.0 | Major-Release |
| 4.1.0 | 4.0.0 | 3.6 | 3.0 | Feature-Update Fachmodul A |
| 5.0.0 | 5.0.0 | 3.7 | 4.0 | Major-Release |
Angabe der XJustiz-Version
Die XJustiz-Version wird weiterhin:
- in den Schemata über das vorhandene
<version>-Element (Kindelement von<versionStandard>) und - in jeder XJustiz-Instanz (XJustiz-Nachricht) über das verpflichtende Attribut
xjustizVersiondes TypsGDS.Nachrichtenkopf
angegeben. (zur Modellierung des Attributs xjustizVersion vgl. unten)
Das Attribut xjustizVersion bezeichnet die normative Release-Version des Gesamtsystems (Baseline), nicht die technische Version des Grunddatensatz-Schemas. Die konkrete Schema-Version ergibt sich weiterhin aus den referenzierten XSD-Dateien.
Im Grunddatensatz ist das Attribut xjustizVersion bis Version 3.6 mit einem fixed-Wert modelliert:
<xs:attribute name="xjustizVersion" type="din91379:datatypeC"
use="required" fixed="3.6.2">
Dies würde zukünftig dazu führen, dass der fixed-Wert bei jedem Feature-Update angepasst werden müsste und sich das Schema des Grunddatensatzes zwangsläufig ändern würde. Da dies im Widerspruch zur definierten Release-Policy „keine Änderung des Grunddatensatzes bei Feature Updates“ steht, wird das Attribut xjustizVersion ab Version XJustiz 4.0 nicht mehr als fixed modelliert, sondern muss einem Pattern („4.x.y“) genügen.
Dies erfolgt durch Einführung eines neuen GDS-Typs:
<xs:simpleType name="Type.GDS.XJustizVersion">
<xs:restriction base="xs:string">
<xs:pattern value="4\.(0|[1-9]\d*)\.(0|[1-9]\d*)"/>
</xs:restriction>
</xs:simpleType>
Die Attributdefinition lautet wie folgt:
<xs:attribute name="xjustizVersion" type=" Type.GDS.XJustizVersion"
use="required"/>
Auf diese Weise wird die Angabe der XJustiz-Version, in der eine XJustiz-Nachricht erstellt wurde, weiterhin XSD-seitig erzwungen. Bei der Validierung kann jedoch entschieden werden, ob gegen das Major-Release oder etwaige Feature-Releases validiert werden soll. Eine genaue Release-Prüfung für Feature Updates kann darüber hinaus optional über Schematron erfolgen.
Auswirkung auf Validierungen
Die Versionsangabe in der XJustiz-Nachricht per Attribut xjustizVersion (z. B. „4.0.0“ oder „4.1.0“) ist für die technische XSD-Validierung nicht mehr ausschlaggebend, da nur noch auf die erste Stelle geprüft wird.
Entscheidend ist, welche XSD-Datei in der XJustiz-Nachricht per schemaLocation referenziert wird und ob der Empfänger genau diesen Schema-Stand auflösen kann.
In den Dateinamen der XJustiz-Schemata werden die ersten beiden Stellen der Versionsnummer abgebildet, zum Beispiel xjustiz_0200_familie_3_1.xsd für ein Fachmodul mit der Versionsnummer 3.1.0. Bei einem Feature Update erhält nur ein tatsächlich geändertes Fachmodul einen neuen Schema-Stand (beispielsweise 3_2 statt 3_1). Unveränderte Fachmodule behalten ihren bisherigen Schema-Stand. Für Nachrichten aus Fachmodulen, die von einem Feature Update nicht betroffen sind, bleibt der referenzierte Schema-Stand unverändert.
Für Nachrichten aus Fachmodulen, die vom Feature Update betroffen sind, verweist die Nachricht i.d.R. auf einen neuen Schema-Stand; dann muss auch gegen diesen neuen Stand validiert werden.
Nicht betroffenes Fachmodul
Ein Feature Update ist aus Sicht der XSD-Validierung weitgehend transparent. Eine Nachricht mit Gesamtversion 4.1.0 kann weiterhin gegen denselben Modul-Schema-Stand geprüft werden wie eine Nachricht aus 4.0.0.
Betroffenes Fachmodul
Das Feature Update ist schema-relevant. Die Nachricht verweist ggf. auf eine neue Modul-XSD und der Empfänger muss genau diesen neuen Stand kennen, um erfolgreich validieren zu können.
Praktisch bedeutet das: Die technische Validierbarkeit hängt nicht primär an der dreistelligen XJustiz-Versionsnummer in der Nachricht, sondern an der Frage, ob der referenzierte Schema-Stand zum Kommunikationsszenario passt.
Entscheidungsbaum
- Aus welcher Fachmodul-XSD stammt die Nachricht?
- Wurde dieses Fachmodul im Feature Update geändert?
- Wenn nein: Validierung ist auch release-übergreifend möglich.
- Wenn ja: Der Empfänger sollte den neuen Schema-Stand des Feature Updates auflösen können.
- Kann der Empfänger die referenzierte XSD-Datei nicht auflösen, scheitert die XSD-Validierung unabhängig von der im Nachrichteninhalt angegebenen Gesamtversion.
Schematron zur Release-Prüfung
Falls zusätzlich geprüft werden soll, dass eine XJustiz-Nachricht exakt einer veröffentlichten und gültigen XJustiz-Version entspricht, kann eine ergänzende Schematron-Regel definiert werden.
Rollenverteilung
strukturelle Generation (Major)
konkrete Release-Compliance
Diese Trennung ist in föderalen Standards üblich und bewährt.