Version:

4.0.0

Status:

Endfassung

Fassung:

Dezember 2025

Herausgeberin:

Koordinierungsstelle für IT-Standards

Kennung:

urn:xoev-de:kosit:xoev:handbuch:xoev-handbuch

Bezugsort:

docs.xoev.de/xoev-handbuch

Lizenz

Creative Commons Namensnennung 4.0

Inhaltsverzeichnis

Vorwort

Die erste Version des Handbuchs zur Entwicklung XÖV-konformer Standards (kurz XÖV-Handbuch) wurde im März 2010 veröffentlicht. Der Kooperationsausschuss Bund-Länder-Kommunaler Bereich (KoopA ADV) hatte diese Version im Rahmen seiner letzten Sitzung verabschiedet und den Einsatz des Handbuchs empfohlen.

Mit Inkrafttreten des Staatsvertrags zur Ausführung von Artikel 91c Grundgesetz (IT-Staatsvertrag) zum 1. April 2010 haben die darin vereinbarten Abstimmungsmechanismen die bisherigen Gremien abgelöst und sind in deren Rechtsnachfolge eingetreten. Seitdem ist der IT-Planungsrat das zentrale Steuerungsgremium für die IT von Bund und Ländern. Im Rahmen dieser Veränderungen haben die E-Government-Staatssekretäre beschlossen, die Koordinierungsstelle für IT-Standards (KoSIT) in Bremen einzurichten. Die OSCI-Leitstelle, die bisher im Rahmen der XÖV-Koordination für das XÖV-Handbuch zuständig war, ist zum 1. April 2011 in die KoSIT überführt worden. Die jetzt in der KoSIT ansässige XÖV-Koordination gibt seit dem das XÖV-Handbuch im Auftrag des IT-Planungsrates heraus.

Seit seiner ersten Veröffentlichung ist das XÖV-Handbuch in über einhundert Vorhaben als Grundlage zur Entwicklung von IT-Spezifikationen zur elektronischen Datenübermittlung eingesetzt worden. Eine Übersicht der aus diesen Vorhaben resultierenden Standards finden Sie auf der Plattform XRepository.

Mit dem XÖV-Handbuch werden sämtliche Regelungen und methodischen Ansätze des XÖV-Standardisierungsrahmens dokumentiert, öffentlich bereitgestellt und fortgeschrieben. Für diese Fortschreibung werden die aus der Praxis der XÖV-Vorhaben gewonnenen Erkenntnisse, die durch sich kontinuierlich entwickelnde nationale und europäische Rahmenbedingungen der Standardisierung entstehenden Änderungsbedarfe sowie der aktuelle Stand der Technik berücksichtigt.

Mit der vorliegenden Version 4.0.0 des XÖV-Handbuchs wird XÖV-Vorhaben die Möglichkeit geboten, aus zwei Ansätzen zur Erstellung und Fortschreibung eines XÖV-Standards den für ihre Ausgangssituation und Zielsetzung geeigneten zu wählen. Neben der bisherigen, auf der Unified Modelling Language (UML) basierenden Notation (im weiteren Verlauf als classic bezeichnet) steht nun eine technisch leichtgewichtige, XML-basierte Notation (im weiteren Verlauf als lite bezeichnet) zur Verfügung. Alle bestehenden Regelungen des XÖV-Standardisierungsrahmens wie auch der Funktionsumfang des zugrundeliegenden Ansatzes und der XÖV-Produkte bleiben durch diese Erweiterung weitestgehend unberührt.

Zielgruppe und Zweck

Das vorliegende XÖV-Handbuch richtet sich an alle Fach- und Führungskräfte, die Vorhaben zur Entwicklung von IT-Spezifikationen im Kontext der Datenübermittlung in der öffentlichen Verwaltung begleiten, bearbeiten oder verantworten. Aus Gründen der Übersichtlichkeit ist es in zwei Teile gegliedert.

Im ersten Teil des Handbuchs wird den an Standardisierungsvorhaben beteiligten Institutionen und Behörden eine Orientierungshilfe an die Hand gegeben. Er beschreibt die Grundlagen, den Aufbau und die intendierte Verwendung des XÖV-Standardisierungsrahmens und stellt die damit verbundenen Anforderungen und Nutzenpotenziale dar.

Der zweite Teil des Handbuchs dient als Leitfaden für Mitarbeiterinnen und Mitarbeiter von Behörden und Dienstleistern, die mit der konkreten Entwicklung, Umsetzung oder dem Betrieb eines (XÖV-)Standards betraut sind. Hier werden Sie umfassend über die praktische Anwendung des XÖV-Standardisierungsrahmens, der XÖV-Modellierungssprache sowie die damit verbundenen Regelungen, Methoden und Bausteine informiert. Ergänzende Informationen wie beispielsweise zu den für die Entwicklung von XÖV-Standards erforderlichen XÖV-Produkten werden an den entsprechenden Stellen des Handbuchs referenziert.

Zudem bietet der zweite Teil des Handbuchs Unterstützung für Mitarbeitende bei Herstellern von IT-Verfahren, die XÖV-basierte Schnittstellen umsetzen oder deren Umsetzung in Betracht ziehen.

Obwohl der XÖV-Standardisierungsrahmen auch organisatorische Aspekte der Standardisierung berücksichtigt, ist er unabhängig vom angewendeten Vorgehensmodell. Daher können die beschriebenen methodischen Ansätze bestehender Rahmenwerke zur Projektorganisation ergänzend genutzt werden.

Ansprechpartner und Mitwirkende

Das XÖV-Handbuch wird von der Koordinierungsstelle für IT-Standards (KoSIT) herausgegeben. Bei Fragen und Rückmeldungen wenden Sie sich bitte an das Funktionspostfach der KoSIT.

An der aktuellen Fassung des Handbuchs haben folgende Personen mitgewirkt:

Tabelle 1. Editoren und mitwirkende Personen
Rolle	Name	Institution
Editor	Lutz Rabe	Koordinierungsstelle für IT-Standards
Editor	Mirco Kuhlmann	LAVA Unternehmensberatung
Mitwirkender	Hauke Edeler	Koordinierungsstelle für IT-Standards
Mitwirkender	Moritz Hanke	Koordinierungsstelle für IT-Standards

Struktur des Dokuments

Mit Teil I, “Grundlagen” des Handbuchs erhalten die an Standardisierungsvorhaben beteiligten Institutionen und Behörden eine Orientierungshilfe.

Kapitel 1, erläutert die grundlegenden Begrifflichkeiten XÖV-Standard, XÖV-Standardisierungsrahmen und XÖV-Entwicklungsprozess.
Kapitel 2, gibt einen Überblick über die im Rahmen des XÖV-Standardisierungsrahmens bereitgestellten Produkte in den Kategorien Regelungen, Bausteine, Werkzeuge und Infrastruktur sowie das zugehörige Änderungsmanagement.
Kapitel 3, beschreibt das Konzept der XÖV-Konformität, die zugehörigen Kriterien sowie den Ablauf der Prüfung und Zertifizierung im Detail.

Der Teil II, “Entwicklung eines XÖV-Standards” widmet sich der praktischen Anwendung des Standardisierungsrahmens und seiner Komponenten in konkreten Vorhaben und Standards.

Kapitel 4, stellt die einzelnen Schritte der Entwicklungsphasen dar, die sowohl neue Vorhaben als auch bestehende Standards durchlaufen – sei es zur Entwicklung eines XÖV-Fachmodells von Grund auf oder zur Fortschreibung eines bestehenden.
Kapitel 5, beschreibt die XÖV-Modellierungssprache, ihre Konzepte sowie deren Umsetzung in den XÖV-Notationen classic und lite.
Kapitel 6, dokumentiert alle XÖV Namens- und Entwurfsregeln im Überblick und im Detail.
Kapitel 7, erläutert mit den sogenannten Good Practices allgemeine Empfehlungen zur Ausgestaltung eines XÖV-Standards.
Kapitel 8, beschreibt die Eigenschaften der XÖV-Bibliothek und ihre Nutzung.
Kapitel 9, beschreibt die Möglichkeiten zur Nutzung der im eigenen Standard oder in anderen Standards definierten oder den mit der XÖV-Bibliothek bereitgestellten Bausteinen detailliert.
Kapitel 10, beschreibt das neue Angebot der XÖV-Koordination im Bereich der sogenannten etablierten Datenmodelle.

Teil I: Grundlagen

1. Einleitung

Informations- und Kommunikationstechnologien (IKT) sind für die öffentliche Verwaltung von entscheidender Bedeutung. Eine wirtschaftliche und effiziente Verwaltung ist ohne den Einsatz von IKT nicht mehr vorstellbar, insbesondere dort, wo eine Zusammenarbeit über die Grenzen einzelner Behörden hinweg realisiert werden soll. Solche Anwendungsfälle stellen besondere Anforderungen, da die erforderliche Interoperabilität auf technischer, semantischer, organisatorischer und rechtlicher Ebene bei allen beteiligten Organisationen geschaffen werden muss.

Die Anforderungen an eine technische Lösung zur Datenübertragung ergeben sich daher nicht nur aus den beteiligten IT-Verfahren und deren Schnittstellen, sondern auch aus den organisatorischen und rechtlichen Regelungen zur Datenübermittlung und Registerführung sowie den wirtschaftlichen Rahmenbedingungen.

Ein IT-Standard zur Datenübermittlung muss diese umfangreichen, komplexen und heterogenen Anforderungen vollständig erfüllen, um seinen vollen Nutzen entfalten zu können. Mit XÖV (XML in der öffentlichen Verwaltung) wurde ein Ansatz geschaffen, der die Erfassung, Abbildung und vollständige Umsetzung solcher Anforderungen in einen Datenübermittlungsstandard systematisch unterstützt.

XÖV steht dabei für das Bestreben, eine gemeinsame Basis für IT-Verfahren durch den Einsatz von standardisierten Technologien und einheitlichen Verfahren bereitzustellen. Dazu stellt die XÖV-Koordination mit dem XÖV-Standardisierungsrahmen ein umfassendes methodisches und technisches Rahmenwerk für die Entwicklung sogenannter XÖV-Standards bereit.

1.1. XÖV-Standards

Ein XÖV-Standard ist eine formale technische Spezifikation für die nachrichtenbasierte, elektronische Datenübermittlung innerhalb der öffentlichen Verwaltung oder im Austausch mit ihr. Ähnlich wie DIN-Normen sind XÖV-Standards offene und allen Interessierten frei zugänglich Standards. Im Unterschied zu Normen, die von nationalen oder internationalen Normungsorganisationen herausgegeben werden, ist ein XÖV-Standard aber per Definition (siehe XÖV-Konformität) immer ein Produkt der öffentlichen Verwaltung. Die Verwaltung hält alle Rechte am Standard und entscheidet über dessen Inhalte und Fortschreibung.

Die formale Qualität eines XÖV-Standards wird durch die XÖV-Zertifizierung der XÖV-Konformität sichergestellt. Die der Prüfung zugrundeliegenden sogenannten XÖV-Konformitätskriterien decken technische, semantische, organisatorische wie rechtliche Aspekte der Entwicklung, Bereitstellung und Fortschreibung von Standards ab. So werden beispielsweise alle XÖV-Standards in einheitlicher Weise durch ihre Metadaten beschrieben und öffentlich über die Plattform XRepository bereitgestellt.

XÖV-Standards haben, wie beispielsweise auch die Normen des DIN oder anderer Normungsorganisationen zunächst einen ausschließlich empfehlenden Charakter. Wie auch bei Normen kann die Verbindlichkeit zur Verwendung eines XÖV-Standards durch Rechts- oder Verwaltungsvorschriften oder durch vertragliche Regelungen hergestellt werden.

1.2. XÖV-Standardisierungsrahmen

Der durch die XÖV-Koordination bereitgestellte XÖV-Standardisierungsrahmen ist ein umfassendes Instrument der Standardisierung, das Vorhaben von der ersten Ermittlung der fachlichen Anforderungen bis zur letztendlichen Bereitstellung eines XML-basierten Standards zur Datenübermittlung unterstützt.

Der XÖV-Standardisierungsrahmen und seine Bestandteile wurden auf Grundlage der spezifischen Anforderungen von Standardisierungsvorhaben der öffentlichen Verwaltung konzipiert und umgesetzt. Ähnlich wie bei anderen Rahmenwerken im Bereich der Softwaretechnik basiert der wesentliche Nutzen des XÖV-Standardisierungsrahmens auf dem Prinzip der Wiederverwendung bestehender Lösungen. Dieses Prinzip umfasst sowohl die einzelnen mit dem XÖV-Standardisierungsrahmen bereitgestellten (XÖV-)Produkte als auch die mit diesen Produkten entwickelten Standards und Codelisten.

Die von der XÖV-Koordination kostenfrei bereitgestellten XÖV-Produkte bieten Standardisierungsvorhaben praxistaugliche und qualitätsgesicherte Lösungen zur wirtschaftlichen Umsetzung der jeweiligen fachlichen Anforderungen bei der Entwicklung und Fortschreibung eines Datenübermittlungsstandards. Die Anwendung der zugrundeliegenden methodischen Vorgehensweise bei der Entwicklung eines XÖV-Standards hilft Verantwortlichen zudem, bestehende Erfahrungen für die Planung und Umsetzung des eigenen Vorhabens zu nutzen und dabei Risiken und Kosten des Projekts im Griff zu behalten.

1.3. XÖV-Entwicklungsprozess

Die Grundlage der Entwicklung eines XÖV-Standards bildet der in Abbildung 1, “Schematische Darstellung der Phasen einer XÖV-Entwicklung” schematisch dargestellte Entwicklungsprozess. Im Folgenden werden die drei Phasen Entwurf, Spezifikation und Produktion des Entwicklungsprozesses detaillierter beschrieben.

Abbildung 1. Schematische Darstellung der Phasen einer XÖV-Entwicklung

1.3.1. Entwurfsphase

In der Entwurfsphase werden die fachlichen Anforderungen an die geplanten Szenarien zur Datenübermittlung erhoben und im sogenannten Fachmodell abgebildet. Dies geschieht in der Regel in einem moderierten Prozess, bei dem die rechtlichen, organisatorischen, semantischen und technischen Rahmenbedingungen und Anforderungen durch die Beteiligten erarbeitet und formalisiert werden. Die Erfassung und Dokumentation der ersten Ergebnisse kann, muss jedoch nicht, durch ein bestimmtes Werkzeug unterstützt werden. Der XÖV-Standardisierungsrahmen sieht für die Dokumentation der Kommunikationsprozesse und Datenstrukturen des zu erstellenden Standards die UML-Notation für Anwendungsfall-, Aktivitäts- und Klassendiagramme vor, um eine verlustfreie Weitergabe von Informationen zwischen Fachexperten und technischen Umsetzern zu erreichen. Eine einheitliche Notation dieser Art erleichtert zudem die Vergleichbarkeit und Nachnutzung der Bestandteile bereits praxiserprobter XÖV-Standards.

1.3.2. Spezifikationsphase

In der Spezifikationsphase werden die in der Entwurfsphase erhobenen Informationen mittels XÖV-Modellierungssprache und einer zugehörigen XÖV-Notation in ein XÖV-Fachmodell überführt. Ziel dieser Phase ist es, alle erforderlichen Informationen zur Umsetzung der Anforderungen in die Bestandteile eines XÖV-Standards in einem zentralen Informationsmodell zu integrieren. Spätestens mit dem Übergang in diese Phase muss ein Standardisierungsvorhaben die Entscheidung für eine XÖV-Notation der XÖV-Modellierungssprache treffen.

1.3.3. Produktionsphase

In der abschließenden Produktionsphase werden alle Bestandteile eines XÖV-Standards werkzeuggestützt aus dem XÖV-Fachmodell generiert. Dies umfasst sowohl die technischen Bestandteile zur Implementierung des XÖV-Standards als auch ein menschenlesbares Spezifikationsdokument. Schon während der Verarbeitung des XÖV-Fachmodells stellt eine in die XÖV-Produktionsumgebung integrierte Prüfumgebung die Einhaltung von XÖV-Regelungen sicher. Den Abschluss der Produktionsphase bildet die XÖV-Zertifizierung.

Der gesamte XÖV-Entwicklungsprozess wird, unabhängig von der genutzten XÖV-Notation, durch die Verwendung der standardisierten grafischen Notation Unified Modeling Language (UML) ergänzt. UML ermöglicht die Abbildung von Datenübermittlungsszenarien in ihren fachlichen und technischen Facetten zur verlustfreien Weitergabe von Informationen zwischen Fachexperten und technischen Umsetzern. Im Kontext der Entwicklung und Fortschreibung eines XÖV-Standards sind insbesondere die Anwendungsfall-, Aktivitäts- und Klassendiagramme der UML-Notation relevant.

2. XÖV-Produkte

Der XÖV-Standardisierungsrahmen ermöglicht die praktische Umsetzung des XÖV-Entwicklungsprozesses (siehe Abschnitt 1.3, “XÖV-Entwicklungsprozess”) durch die Bereitstellung einer Reihe aufeinander abgestimmter, sogenannter XÖV-Produkte. Im Folgenden wird zunächst eine Übersicht über die Produkte und ihre Einordnung in den Entwicklungsprozess gegeben. Eine detailliertere Beschreibung der relevantesten XÖV-Produkte der Kategorien Regelungen, Werkzeuge, Bausteine und Infrastrukturkomponenten ist in den anschließenden Abschnitten gegeben.

Standardisierungsvorhaben werden schon in der frühen Entwurfsphase durch die Bereitstellung von Informationen zu bestehenden Lösungen unterstützt. Die in den XÖV-Konformitätskriterien enthaltenen Bereitstellungs- und Auskunftspflichten halten die Verantwortlichen der XÖV-Vorhaben zur Veröffentlichung von Informationen zu den Standardisierungsvorhaben auf der Plattform XRepository an. Diese Regelung stellt sicher, dass Personen, die neue Vorhaben planen, sich an zentraler Stelle darüber informieren können, ob für ihre Anforderungen bereits ein Standard existiert oder in Planung ist. Auch können bestehende Lösungen möglicherweise in das eigene (XÖV-)Fachmodell übernommen werden.

Sind die Konzepte zur Deckung der fachlichen Anforderungen im Fachmodell abgebildet, können sie im Detail spezifiziert werden. Grundlage hierzu sind die Verpflichtungen der XÖV-Namens- und Entwurfsregeln. Sie geben einen praktischen Leitfaden zur technischen Umsetzung der fachlichen Konzepte in das XÖV-Fachmodell und ermöglichen zudem die nahtlose Integration „externer“ Lösungen in den eigenen Standard. Beispiele hierfür sind die mit der XÖV-Bibliothek bereitgestellten (XÖV-)Bausteine für den Bereich Datenstrukturen und die im XRepository bereitgestellten Bausteine aus dem Bereich Codelisten.

Die konkrete Spezifikation des XÖV-Fachmodells erfolgt in der XÖV-Modellierungssprache mit den Mitteln der XÖV-Produktionsumgebung und dem darin enthaltenen XÖV-Profil für Modelle in der classic-Notation beziehungsweise dem enthaltenen lite-(XSD-)Schema für Modelle in der lite-Notation. Beide Notationen ermöglichen die XÖV-spezifische Detaillierung eines XÖV-Fachmodells, die für die weitere Bearbeitung notwendig ist.

Aus dem so entstandenen XÖV-Fachmodell werden unter Zuhilfenahme des XGenerators und der darin genutzten XÖV-Produktionsumgebung die Bestandteile eines XÖV-Standards produziert.

Nach Abschluss der Produktion stellen Vorhaben das XÖV-Fachmodell und die Bestandteile des Standards über das XRepository zum Bezug bereit und melden den Standard direkt über die Plattform zur Zertifizierung an.

Eine ausführlichere Übersicht zu den Produkten des XÖV-Standardisierungsrahmens ist in den folgenden Abschnitten gegeben. Weitergehende Informationen zu den hier dargestellten und weiteren Produkten sind auf der XÖV-Dokumentationsplattform (XÖV docs) verfügbar. Hier finden Sie auch Informationen zu den Möglichkeiten, sich an der Weiterentwicklung des XÖV-Standardisierungsrahmens und seiner Produkte zu beteiligen, indem Sie Änderungswünsche oder Fehler zu den jeweiligen Produkten melden können.

2.1. XÖV-Regelungen

Mit den Regelungen des XÖV-Standardisierungsrahmens wird das Ziel verfolgt, das dem XÖV-Entwicklungsansatz zugrundeliegende Prinzip der Wiederverwendung bestehender Lösungen in der praktischen Entwicklungsarbeit der Standards zu verankern. XÖV-Regelungen geben den Standardisierungsvorhaben eine praktische Handlungsgrundlage bei der Verwendung der mit dem Rahmenwerk bereitgestellten Komponenten und helfen dabei gleichzeitig, Ergebnisse der Standardisierung strukturell zu vereinheitlichen und somit deren (Wieder-)Verwendung zu vereinfachen.

2.1.1. XÖV-Konformitätskriterien und Namens- und Entwurfsregeln

Das Regelwerk des XÖV-Standardisierungsrahmens setzt sich zusammen aus den XÖV-Konformitätskriterien und den XÖV-Namens- und Entwurfsregeln (engl. Naming and Design Rules, kurz NDR). Während die Konformitätskriterien das grundsätzliche Vorgehen im XÖV-Entwicklungsprozess regeln, legen die Namens- und Entwurfsregeln insbesondere die technische Ausgestaltung eines XÖV-Standards fest. Für die Konformitätskriterien wie auch die Namens- und Entwurfsregeln sind die Verbindlichkeitsstufen SOLL und MUSS gegeben.

Alle Regelungen des XÖV-Standardisierungsrahmens sind in diesem Handbuch unter Kapitel 3, und Kapitel 6, vollständig dokumentiert.

2.1.2. Good Practices

Neben den Regelungen mit den Verbindlichkeitsstufen SOLL und MUSS existieren im Bereich der technischen Ausgestaltung auch die sogenannten Good Practices (Verbindlichkeitsstufe Good Practice). Sie dokumentieren in der Praxis bewährte Namens- und Entwurfsmuster und können helfen, den Entwicklungsaufwand zu reduzieren sowie die Einheitlichkeit und damit die Zugänglichkeit eines XÖV-Standards zu verbessern. Die in Kapitel 7, beschriebenen Empfehlungen sind nicht zertifizierungsrelevant, können aber mit der in der XÖV-Produktionsumgebung ausgelieferten Prüfumgebung automatisiert auf das XÖV-Fachmodell angewendet werden.

2.2. XÖV-Bausteine

Bausteine beschreiben die Datenstrukturen und -formate eines Standards, die mehrfach innerhalb des eigenen Standards, aber auch Standard-übergreifend genutzt werden können. XÖV-Bausteine sind Bausteine, die durch die XÖV-Koordination originär betrieben bzw. konsolidiert und mit dem XÖV-Standardisierungsrahmen zur Nutzung in XÖV-Standards bereitgestellt werden. Die Bereitstellung erfolgt zentral über die XÖV-Bibliothek. Ausgenommen hierbei sind die XÖV-Codelisten, die im XRepository zur Verfügung stehen.

Die Nutzung der XÖV-Bausteine ermöglicht Standardisierungsvorhaben die effiziente und wirtschaftliche Umsetzung eigener Anforderungen auf der Basis praxisgeprüfter und qualitätsgesicherter Lösungen.

Gleichzeitig bieten gemeinsam genutzte Bausteine aus Sicht der XÖV-Koordination die Möglichkeit, die Vielzahl bestehender Lösungen zu harmonisieren. So steigert eine übergreifende Wiederverwendung von Bausteinen die technische und semantische Interoperabilität zwischen XÖV-Standards und hilft durch diese Vereinheitlichung die Kosten der Implementierung eines XÖV-Standards in eine IT-Verfahrensschnittstelle zu reduzieren.

Die XÖV-Bausteine haben entweder einen fachunabhängigen oder fachübergreifenden Charakter. Fachunabhängige Bausteine, wie zum Beispiel ein Datentyp mit den Grundstrukturen zur Übermittlung von Codes aus Codelisten, stellen grundlegende, technische Lösungsansätze dar, die in allen Datenübermittlungsszenarien eingesetzt werden können und sollen. Fachübergreifende Bausteine, wie zum Beispiel die Anschrift einer natürlichen Person, können in bestimmten Fachbereichen als Grundlage zur Umsetzung konkreter, fachspezifischer Anforderungen dienen.

XÖV-Bausteine liegen in den Bereichen Datentypen, globale Eigenschaften(gruppen) und Codelisten vor. Zur Unterstützung der oben genannten Ziele wird die Verwendung der XÖV-Bausteine durch das XÖV-Rahmenwerk sowohl methodisch als auch regulatorisch unterstützt. Detaillierte Informationen zur Verwendung der einzelnen Bausteinarten sind in Kapitel 9, dargestellt.

2.2.1. XÖV-Datentypen und globale Eigenschaften(gruppen)

XÖV-Datentypen und globale Eigenschaften(gruppen) stellen fundamentale, meist fachunabhängig nutzbare Bausteine dar, deren Einsatz in unveränderter Form in allen XÖV-Standards vorgesehen ist. Sie liegen als XML-Datentypen, -Elemente, -Attribute oder XML-Gruppen vor und werden auf der Ebene von XML Schema schließlich in die Bestandteile des Standards eingebunden. Durch die XÖV-Bibliothek werden sie hierfür zur direkten Nutzung im XÖV-Fachmodell bereitgestellt. Die Bibliothek umfasst derzeit die im Folgenden aufgeführten XÖV-Datenstrukturen und -formate:

Datentyp zur Übermittlung von Codes: Der Datentyp Code wird genutzt, um Codes aus Codelisten zu übermitteln. Er wird von der KoSIT als Bestandteil des XÖV-Standardisierungsrahmens betrieben.
Datentypen zur Übermittlung von Teilmengen der in Unicode enthaltenen Zeichen: Der Datentyp String.Latin des Standards "Lateinische Zeichen in Unicode" und die Datentypen A bis E der DIN 91379 "Zeichen in Unicode für die elektronische Verarbeitung von Namen und den Datenaustausch in Europa"^[1] bestimmen unterschiedliche Teilmengen der im Standard "Unicode" definierten Zeichen.
Datentypen und globale Eigenschaften zur XÖV-Basisnachricht: Die XÖV-Basisnachricht legt die Grundstruktur von XÖV-Nachrichten fest. Sie beinhaltet Angaben zur eindeutigen Identifikation der Nachricht, des Autors und des Lesers (Routinginformationen) sowie zum Standard und dem eingesetzten Fachverfahren.
Datentypen und globale Eigenschaften zu Datenmodell-Syntaxen: Datenmodell-Syntaxen umfassen die technisch ausgeprägten XÖV-Bausteine zur Nutzung etablierter Datenmodelle auf der Basis der mit den Datenmodellen assoziierten XÖV-Standards. Die konkreten XÖV-Bausteine stellen dabei einerseits Originalbausteine der eigenständig betriebenen XÖV-Standards dar, andererseits von der XÖV-Koordination betriebene aufbereitete Originalbausteine. Weitere Informationen zu etablierten Datenmodellen und Datenmodell-Syntaxen sind den folgenden Abschnitten gegeben.

2.2.2. Etablierte Datenmodelle

Etablierte Datenmodelle im XÖV-Kontext sind Modelle, die einen klar definierten Satz von Eigenschaften besitzen. Sie beschreiben fachlich-semantische Konzepte und ermöglichen deren übergreifende Nutzung. Für die Inhalte und deren Pflege ist jeweils ein verantwortlicher Herausgeber benannt. Zudem ist ihre Verwendung innerhalb eines festgelegten Rahmens verbindlich geregelt.

Derzeit werden im XÖV-Kontext Etablierte Datenmodelle für folgende Bereiche unterstützt:

Basisdaten einer natürlichen Person
Schriftgutobjekte
Stammdaten eines Unternehmens

Datenmodell-Syntaxen

Grundsätzlich können Datenmodelle technologieneutral gestaltet sein. Für die praktische Anwendung innerhalb eines XÖV-Standards ist jedoch eine konkrete technische Ausprägung erforderlich. Die XÖV-Koordination stellt daher für jedes unterstützte Etablierte Datenmodell XÖV-konforme technische Ausprägungen bereit. Diese werden im Folgenden als Datenmodell-Syntaxen (kurz DM-Syntaxen) bezeichnet.

Wie alle Inhalte des XÖV-Rahmenwerks unterliegen auch Etablierte Datenmodelle und ihre technischen Ausprägungen einem geregelten Betrieb. Alle im XÖV-Angebot genutzten und bereitgestellten Versionen werden über einen definierten Satz von Metadaten beschrieben. Die Grundlage für eine geregelte Nutzung in XÖV-Standards, die technische Umsetzung und die Versionierung bilden dabei die mit den unterstützten Datenmodellen assoziierten XÖV-Standards XBasisdaten, xdomea und XUnternehmen.Basismodul.

Semantik Etablierter Datenmodelle

Bei der Definition von Datenmodellen und der Spezifikation zugehöriger Syntaxen finden unterschiedliche Ansätze Verwendung, teils Datenmodell und Syntax kombinierend (durch eine Verknüpfung semantischer Beschreibungen mit technischen Festlegungen), teils Datenmodell und Syntax explizit trennend (Beispiel: XUnternehmen mit einer Trennung in ein Kerndatenmodell und ein Basismodul).

XÖV-Angebot zu etablierten Datenmodellen

DM-Syntaxen zu Etablierten Datenmodellen werden in der XÖV-Bibliothek bereitgestellt. Zum Angebot gehören die Originalbausteine der mit den Datenmodellen assoziierten XÖV-Standards sowie zur leichteren Nachnutzung aufbereitete Originalbausteine (siehe hierzu Kapitel 10, ). Wo geboten, werden die Inhalte in mehreren Modellierungsvarianten bereitgestellt. Dabei werden Hinweise auf zentrale Bausteine einer DM-Syntax gegeben sowie Details zum Aufbau dieser Bausteine.

Die Bereitstellung der Inhalte zu etablierten Datenmodellen wird mit den Releases der XÖV-Bibliothek ab Q1 2026 beginnen.

2.2.3. XÖV-Codelisten

Zum Codelisten-Handbuch konforme Codelisten werden über die Infrastrukturkomponente XRepository zur standardübergreifenden Nutzung öffentlich bereitgestellt. Eine XÖV-Codeliste ist eine solche Codeliste, die durch die XÖV-Koordination betrieben und bereitgestellt wird. Diese Codelisten sind XÖV-Bausteine und betreffen einige zentrale Themenfelder. Sie werden zur standardübergreifenden Nutzung besonders empfohlen. Folgende XÖV-Codelisten werden bereitgestellt: Erreichbarkeit, Country Codes, Currency Codes und Verzeichnis-Dienste.

2.3. Werkzeuge

Die Werkzeuge des XÖV-Standardisierungsrahmens ermöglichen die konkrete Anwendung der XÖV-Modellierungssprache und einer zugehörigen Notation im XÖV-Fachmodell sowie dessen Prüfung und weitere Verarbeitung.

2.3.1. XÖV-Produktionsumgebung

Die XÖV-Produktionsumgebung stellt die zentrale Umgebung dar, in der die Inhalte eines XÖV-Standards spezifiziert, d. h. die Inhalte eines Fachmodells technisch konkretisiert, und produziert werden.

Sie umfasst auf der einen Seite die Inhalte zur Verwendung der XÖV-Modellierungssprache in den Notationen classic und lite. Auf der anderen Seite bringt sie alle Informationen mit, auf deren Basis das XÖV-Fachmodell automatisiert geprüft und in die darin spezifizierten Bestandteile übersetzt werden kann.

Abbildung 2. Bestandteile der XÖV-Produktionsumgebung

In den folgenden Abschnitten werden die vier inhaltlichen Bereiche der XÖV-Produktionsumgebung in einer Übersicht beschrieben. Weitere Informationen sind in Abschnitt 4.3, “Produktionsphase” und über XÖV docs unter XÖV-Produktionsumgebung bereitgestellt.

Inhalte für die `classic` Notation

Für die Spezifikation eines XÖV-Fachmodells in der classic Notation stellt die XÖV-Produktionsumgebung das so genannte XÖV-Profil bereit, welches XÖV-spezifische Stereotypen und die W3C-Datentypen des W3C zur Nutzung auf der UML-Ebene umfasst.

UML-Stereotypen

In der Unified Modeling Language (UML) werden so genannte "Stereotypen" zur Erweiterung der allgemeingültigen Sprache um die in einem bestimmten Kontext (z. B. XÖV) benötigten Sprachelemente eingesetzt.

Die mit dem XÖV-Profil bereitgestellten Stereotypen repräsentieren die Sprachelemente der XÖV-Modellierungssprache und werden somit eingesetzt um den Inhalten eines UML-Modells ihre XÖV-spezifische Bedeutung zu geben, zum Beispiel zur Kennzeichnung einer UML-Klasse als Nachricht.

Inhalte für die `lite` Notation

Für die Spezifikation eines XÖV-Fachmodells in der lite Notation stellt die XÖV-Produktionsumgebung ein entsprechendes XSD-Schema bereit, welches die Verwendung der XÖV-Modellierungssprache auf der Ebene XML regelt. Das Schema spezifiziert die verfügbaren Sprachelemente und bestimmt die im XÖV-Fachmodell erlaubten bzw. erforderlichen Strukturen und Formate.

Prüfanweisungen

Die XÖV-Produktionsumgebung umfasst Anweisungen zur automatisierten Prüfung eines XÖV-Fachmodells, die sowohl dem Standardisierungsvorhaben als auch der Zertifizierungsstelle zur Sicherstellung eines fehlerfreien, konsistenten und XÖV-konformen Standards dienen.

Dabei werden automatisiert prüfbare XÖV-Namens- und Entwurfsregeln und Good Practices als Prüfanweisungen bereitgestellt, die sowohl für die classic Notation als auch die lite Notation Anwendung finden. Darüber hinaus werden für die classic Notation zusätzlich Prüfanweisungen zur Sicherstellung eines konsistenzen Einsatzes der XÖV-Stereotypen bereitgestellt. Alle Prüfanweisungen werden durch das Werkzeug "XGenerator" ausgeführt und ein entsprechendes Prüfprotokoll bereitgestellt.

Übersetzungsanweisungen

Zur Überführung eines XÖV-Fachmodells in die Bestandteile eines XÖV-Standards werden entsprechende Übersetzungsanweisungen benötigt, die mit der XÖV-Produktionsumgebung zur Verfügung gestellt werden. Diese Anweisungen erlauben insbesondere die automatisierte Erzeugung der XSD-Schemas des Standards sowie der technischen Bestandteile des Spezifikationsdokuments. Darüber hinaus ist die Generierung von WSDL-Dokumenten zur Beschreibung von Diensten möglich. Bei Verwendung der classic Notation ist zusätzlich die Möglichkeit gegeben, aus den eigenen, im XÖV-Fachmodell spezifizierten Codelisten wiederum Codelisten im Genericode-Format zu erzeugen. Ebenso wie die Prüfanweisungen werden die Übersetzungsanweisungen durch den XGenerator auf das XÖV-Fachmodell angewendet.

2.3.2. XGenerator

Der XGenerator ist ein Werkzeug, das sowohl die automatisierte Prüfung des XÖV-Fachmodells als auch die Erzeugung der Bestandteile des Standards ermöglicht. Die entsprechenden Prüf- und Übersetzungsanweisungen werden dem XGenerator mit der XÖV-Produktionsumgebung zur Verfügung gestellt.

Ausgangspunkt der Produktion ist das XÖV-Fachmodell in einer maschinenlesbaren Darstellung in der classic Notation (XMI-Format) oder der lite Notation (XML-Format).

XMI-Format

Eine XMI-Darstellung des XÖV-Fachmodells in der classic Notation wird in der Regel über die Export-Funktion des UML-Modellierungswerkzeugs erzeugt. Die aktuellen Versionen des XGenerators (3.n) sind mit der XMI-Version “Eclipse UML2 v5.x” getestet und konform.^[2]

Weitere Informationen zum Produkt sind über XÖV docs unter XGenerator bereitgestellt.

2.4. Infrastruktur

Zur Bereitstellung, zum Bezug und zur Nutzung der vielfältigen Inhalte und Informationen im XÖV-Kontext steht mit dem XÖV-Standardisierungsrahmen eine entsprechende Infrastruktur in verschiedenen Ausprägungen zur Verfügung.

Hierzu gehören das XRepository als zentrale Plattform für die Distribution, die XÖV suite zur Exploration und Modellierung von XÖV-Standards, die XÖV-Bibliothek zur Bereitstellung von XÖV-Bausteinen sowie XÖV docs als zentraler Ort für Informationen und Inhalte rund um das XÖV-Rahmenwerk und seine Produkte.

2.4.1. XRepository

Das XRepository ist die XÖV-Distributionsplattform zur Unterstützung der Entwicklungs- und Bereitstellungsprozesse eines Standards, seine XÖV-Zertifizierung wie auch seine operative Nutzung.

Alle Bestandteile eines XÖV-Standards sowie die für den Datenaustausch notwendigen Artefakte wie Codelisten können über das XRepository sowohl manuell als auch automatisiert (per REST-Schnittstelle) bezogen werden. Das XRepository ist somit für Verfahrenshersteller, Betreiber von IT-Verfahren, Betreiber von XÖV-Standards, Herausgeber von Codelisten und die XÖV-Koordination ein wichtiges Werkzeug für die tägliche Arbeit.

Weitere Informationen zum Produkt sind über XÖV docs unter XRepository bereitgestellt.

2.4.2. XÖV suite

Die XÖV suite richtet sich gleichermaßen an XÖV-Vorhaben, die einen Standard erstellen und fortschreiben möchten, sowie an diejenigen, die XÖV-Standards nutzen, profilieren, in IT-Verfahren umsetzen, auf sie verweisen oder sie im Detail begutachten wollen.

Für XÖV-Vorhaben stellt die XÖV suite grundlegende Funktionen zur initialen Erstellung und zur Fortschreibung eines XÖV-Fachmodells bereit. Die Verarbeitung des Fachmodells erfolgt dabei stets auf Basis der aktuellen Fassung der XÖV-Produktionsumgebung. Die zentralen Bestandteile des Standards werden automatisiert aus dem XÖV-Fachmodell generiert und können zusammen mit dem Gesamtprojekt aus der suite exportiert werden.

Für die Nutzenden von XÖV-Standards bietet die XÖV suite Funktionen zur Exploration und Profilierung.

Die Explorationsfunktionen ermöglichen eine detaillierte Analyse der Nachrichten und der darin verwendeten Bausteine eines XÖV-Standards. Neben der präzisen Anzeige der Nachrichten werden auch alle genutzten Bausteine (Datentypen, globale Elemente, Codelisten etc.) sowie deren Dokumentation umfassend dargestellt.

Die Profilierungsfunktionen erlauben es, einen bestehenden XÖV-Standard auf organisatorischer, semantischer oder technischer Ebene einzuschränken. Ergebnis einer Profilierung ist neben der Dokumentation aller Einschränkungen auch deren technische nutzbare Umsetzung in Form einer Schematron-Datei.

Abgerundet wird das Funktionsspektrum durch die Möglichkeit, Nachrichten konform zu einem Standard oder einer Profilierung zu erzeugen, zu visualisieren und gegen den zugrunde liegenden Standard oder ein Profil zu validieren. Darüber hinaus können auch eigene Nachrichten in die XÖV suite geladen werden.

Nutzung der Modellierungsfunktionen

Die Bereitstellung der Funktionen zur Modellierung von XÖV-Standards wird ab Q1 2026 beginnen.

2.4.3. XÖV-Bibliothek

Mit der XÖV-Bibliothek werden den Standardisierungsvorhaben alle durch die XÖV-Koordination herausgegebenen XÖV-Bausteine zur Verfügung gestellt, ausgenommen XÖV-Codelisten, welche mit den weiteren existierenden Codelisten im XRepository bereitgestellt werden.

Die XÖV-Bibliothek erlaubt eine komfortable und einheitliche Einbindung und Nutzung dieser Bausteine in XÖV-Standards. Veröffentlicht wird die Bibliothek, den XÖV-Prinzipien zur Entwicklung von Standards folgend, in der Form eines Modells in den Notationen classic und lite. Damit kann sie als externes Modell direkt in ein XÖV-Fachmodell eingebunden und die enthaltenen Bausteine unkompliziert genutzt werden.

Weitere Informationen zur Bibliothek sind in Kapitel 8, sowie über XÖV docs unter XÖV-Bibliothek bereitgestellt.

2.4.4. XÖV-Dokumentationsplattform

Auf der XÖV-Dokumentationsplattform (kurz XÖV docs) werden die Inhalte und Informationen zum XÖV-Standardisierungsrahmen, seiner Produkte und Releases sowie zu deren Betrieb und Support bereitgestellt. Informationen zu gültigen XÖV-Konfigurationen sind auf ihr ebenso einsehbar wie Antworten zu häufig gestellten Fragen und Anleitungen zu speziellen Fragestellungen. Im Download-Bereich der Plattform stehen alle gegenwärtig gültigen Produkte zum Bezug bereit. Zu jedem XÖV-Produkt sind detaillierte Informationen, z. B. zu Zielgruppe, Methodik, verschiedenen Ausprägungen und Betrieb, verfügbar. In diesem Zusammenhang werden auf der Plattform auch anstehende Schulungsangebote gelistet und die Möglichkeit zur Anmeldung gegeben.

2.5. Änderungsmanagement

Das Änderungsmanagement ist ein zentrales Instrument für den Betrieb des XÖV-Standardisierungsrahmens und seiner Komponenten. Änderungsmanagement soll hier verstanden werden als strukturierte Erfassung, Bewertung und Entscheidung von Änderungsanträgen zu den XÖV-Produkten.

XÖV-Produkte sind einzelne oder zusammengefasste Komponenten des XÖV-Standardisierungsrahmens, wie beispielsweise der XGenerator, die XÖV-Bausteine oder das XÖV-Handbuch. Alle Produkte sind auf XÖV docs unter den jeweiligen Kategorien dargestellt. Neben den grundlegenden Informationen zu den Produkten werden an dieser Stelle auch Informationen zur Release-Planung und den für die Umsetzung eingeplanten Änderungsanträgen gegeben.

Eine produktübergreifende Übersicht aktueller XÖV-Releases ist auf XÖV docs unter aktuelle Releases im Überblick zu finden.

Änderungsanträge können prinzipiell durch alle Personen gestellt werden, die direkt oder indirekt an der Entwicklung oder Pflege eines XÖV-Standards beteiligt sind. Neben einem beschreibenden Text sollte ein Änderungsantrag Informationen zum Antragsteller (Name, Organisation und E-Mail-Adresse) und dem Kontext des Antrags und seiner Motivation enthalten.

Betriff der Änderungsantrag ein spezifisches Produkt so kann er direkt über die Seite des Produkts auf XÖV docs gestellt werden. Sofern Ihr Änderungswunsch kein spezielles XÖV-Produkt betrifft, können Sie Ihren Änderungsantrag selbstverständlich auch direkt per E-Mail an die KoSIT (kosit@finanzen.bremen.de) richten. Mit der Erfassung des Antrags übernimmt die KoSIT die Koordination der weiteren Bearbeitung und kann somit auch Auskunft zur Bewertung und zum Bearbeitungsstand des Antrags geben.

3. XÖV-Konformität

Das Prinzip der Wiederverwendung, das dem XÖV-Standardisierungsrahmen zugrunde liegt, sowie die Erschließung der damit verbundenen Nutzenpotenziale erfordern bestimmte Voraussetzungen. Die von der XÖV-Koordination und den XÖV-Standards angebotenen, praxiserprobten und qualitätsgesicherten Lösungen können nur dann in einem Vorhaben wiederverwendet werden, wenn sie hinreichend bekannt und dokumentiert, frei verfügbar sowie sowohl technisch als auch semantisch konform mit dem eigenen Standardisierungsvorhaben sind.

Die Vorgaben und Regelungen des XÖV-Standardisierungsrahmens wurden entwickelt, um diese Voraussetzungen zu erfüllen und dadurch sowohl für einzelne Vorhaben als auch für die öffentliche Verwaltung insgesamt Nutzen zu stiften.

Die XÖV-Regelungen sind in die Bereiche Konformitätskriterien und Namens- und Entwurfsregeln strukturiert. Konformitätskriterien decken die unterschiedlichen methodischen, organisatorischen und technischen Bereiche eines Standardisierungsvorhabens ab. Demgegenüber wird mit den Namens- und Entwurfsregeln ausschließlich die technische Ausgestaltung des Standards geregelt.

Mit der Veröffentlichung einer neuen XÖV-Version, also einer neuen Version des XÖV-Handbuchs und seiner Regelungen, beginnt eine Übergangsfrist von 36 Monaten. Nach Ablauf dieser Frist verliert die Vorgängerversion ihre Gültigkeit und kann nicht mehr zur Prüfung der XÖV-Konformität eines Standards herangezogen werden. Bereits zertifizierte Fassungen eines XÖV-Standards sind davon nicht betroffen.

Für jede Version der XÖV-Regelungen existiert eine darauf abgestimmte XÖV-Produktionsumgebung. Die Nutzung einer gültigen Kombination von XÖV-Handbuch und XÖV-Produktionsumgebung-Version ist eine technische Voraussetzung für die Entwicklung eines XÖV-Standards. Eine Übersicht der aktuell gültigen XÖV-Konfigurationen ist auf XÖV docs unter Gültige Konfigurationen dargestellt.

3.1. XÖV-Konformitätskriterien

XÖV-Konformitätskriterien sind konkrete Prüfkriterien, die ein XÖV-Standard erfüllt. Sie sind in die vier Bereiche

Bereitstellungspflichten,
Auskunftspflichten,
Wiederverwendung sowie
technische Kriterien

unterteilt.

Es wird zwischen den Verbindlichkeitsstufen MUSS und SOLL unterschieden:

MUSS: Kriterien dieser Verbindlichkeitsstufe müssen durch ein XÖV-Vorhaben und seinen Standard eingehalten werden.
SOLL: Kriterien dieser Verbindlichkeitsstufe ermöglichen die Abweichung des XÖV-Vorhabens und seines Standards. Der Ansatz der kontinuierlichen Verbesserung erfordert allerdings, dass die Begründung für die Abweichung zur Zertifizierung dokumentiert wird.

Die in Tabelle 2, “Übersicht der XÖV-Konformitätskriterien” dargestellten Konformitätskriterien bilden die Grundlage zur Prüfung der XÖV-Konformität. Die im Anschluss gegebene Beschreibung enthält sowohl die Begründung der einzelnen Kriterien als auch die in der Konformitätsprüfung jeweils genutzten Prüfgrundlagen und Prüfinhalte.

Tabelle 2. Übersicht der XÖV-Konformitätskriterien
Nr.	Verbindlichkeit	Titel
Bereitstellungspflichten
K-1	`MUSS`	Ein Standard der öffentlichen Verwaltung
K-2	`MUSS`	Freie Verwendung
K-3	`MUSS`	Dokumentation
K-4	`MUSS`	Veröffentlichung
K-5	`MUSS`	Nachhaltigkeit des Standards
Auskunftspflichten der entwickelnden und betreibenden Stellen
K-6	`MUSS`	Anzeige der Entwicklungsabsicht
K-7	`MUSS`	Informationen zum Status des Standards
Wiederverwendung
K-16	`SOLL`	Nutzung der Bausteine der XÖV-Bibliothek
K-13	`SOLL`	Nutzung von Codelisten
Technische Kriterien
K-8	`SOLL`	Modellierung der Prozesse
K-9	`MUSS`	Modellierung der Datenstrukturen
K-10	`MUSS`	Einhaltung der XÖV-Namens- und Entwurfsregeln
K-14	`MUSS`	Verarbeitung des XÖV-Fachmodells durch die XÖV-Produktionsumgebung
K-15	`SOLL`	Nutzung bestehender Infrastruktur

3.1.1. Bereitstellungspflichten

Diese Kriterien klären, von wem und wie ein XÖV-Standard bereitzustellen ist. Insbesondere werden die Mindestanforderungen an die Offenheit eines XÖV-Standards festgelegt.

K-1 `MUSS`: Ein Standard der öffentlichen Verwaltung

Eigentümerin des XÖV-Standards muss die öffentliche Verwaltung sein, d. h. sie bestimmt seine Inhalte und hat alle Rechte am Standard inne. Weiter entscheidet sie über Entwicklung und Pflege sowie über die Verwendung des Standards.

Begründung: Die Entscheidung der öffentlichen Verwaltung über ihre Prozesse soll nicht durch kommerzielle Abhängigkeiten geprägt werden.

Prüfgrundlage: Im XRepository bereitgestellter Standard mit beantragter XÖV-Zertifizierung

Prüfinhalt: Bei der Beantragung der XÖV-Zertifizierung im XRepository wurde explizit bestätigt, dass sich der Standard und seine Version im Besitz der öffentlichen Verwaltung der Bundesrepublik Deutschland befinden.

K-2 `MUSS`: Freie Verwendung

Der XÖV-Standard muss frei von Rechten Dritter sein. Er muss innerhalb der öffentlichen Verwaltung der Bundesrepublik Deutschland und für die Nutzer ihrer Dienstleistungen uneingeschränkt und unentgeltlich verwendbar sein und bleiben.

Begründung: Mit der freien Verfügbarkeit möchte man die Herstellerunabhängigkeit von Schnittstellen und deren Wiederverwendbarkeit fördern.

Prüfgrundlage: Im XRepository bereitgestellte Bestandteile des Standards und seiner Version

Prüfinhalt: Alle Bestandteile des Standards und seiner Version sind frei von Rechten Dritter

K-3 `MUSS`: Dokumentation

Ein XÖV-Standard muss alle erforderlichen Informationen bereitstellen, um eine standard-konforme Schnittstelle für IT-Verfahren entwickeln zu können. Hierzu gehören zwingend die Beschreibung des Standards durch seine Metadaten sowie die Bereitstellung der XSD-Schemas und eines dazu konsistenten Spezifikationsdokuments. Die Regelungen zur Abbildung der Metadaten eines XÖV-Standards sind in NDR-32 dargestellt.

Begründung: Eine standard-konforme Schnittstelle für IT-Verfahren kann nur (weiter-)entwickelt werden, wenn der XÖV-Standard und seine Version über ihre Metadaten eindeutig identifiziert und beschrieben werden können und alle zur Implementierung notwendigen Informationen zur Verfügung stehen.

Prüfgrundlage: Im XRepository bereitgestelltes XÖV-Fachmodell^[3], XSD-Schemas und Spezifikationsdokument des Standards liegen vollständig und konsistent vor

Prüfinhalt: XÖV-Fachmodell^[3], Spezifikationsdokument und zugehörige XSD-Schemas des Standards

K-4 `MUSS`: Veröffentlichung

Der XÖV-Standard muss mit seinem Spezifikationsdokument als PDF-Datei, seinen XSD-Schemas, seinem XÖV-Fachmodell sowie seinem Pflegekonzept nach erfolgter Finalisierung unverzüglich im XRepository öffentlich bereitgestellt werden. Die anschließende Zertifizierung ist ausschließlich über das XRepository zu beantragen. Darüber hinaus müssen alle durch den Standard genutzten Codelisten, wenn sie durch den Standard herausgegeben werden, im XRepository öffentlich bereitgestellt sein.

Begründung: Das XRepository ist die zentrale Distributionsplattform des XÖV-Standardisierungsrahmens.

Prüfgrundlage: Im XRepository bereitgestelltes XÖV-Fachmodell, die im Kontext des Standards herausgegebenen Codelisten und Bestandteile des Standards und seiner Version

Prüfinhalt: Existenz von XSD-Schemas, Spezifikationsdokument in PDF, XÖV-Fachmodell^[3], im Kontext des Standards herausgegebenen Codelisten sowie Pflegekonzept

K-5 `MUSS`: Nachhaltigkeit des Standards

Für den XÖV-Standard muss ein Pflegekonzept vorliegen, aus dem erkennbar wird, dass eine langfristige Wartung und Fortschreibung gewährleistet wird.

Begründung: Investitionssicherheit für implementierende IT-Verfahrenshersteller sowie für Standards, die explizit auf anderen Standards aufbauen, soll sichergestellt werden.

Prüfgrundlage: Im XRepository bereitgestellte Bestandteile des Standards

Prüfinhalt: Existenz eines Pflegekonzeptes mit Angaben zu den Aufgaben, Rollen und Verantwortlichkeiten, zur pflegenden Stelle sowie zur Finanzierung des Pflegebetriebs

3.1.2. Auskunftspflichten der entwickelnden und betreibenden Stellen

Auskunftspflichten beziehen sich auf Kriterien, bei denen die Verantwortlichen eines Standards Informationen zu ihrem Vorhaben aufbereiten und veröffentlichen. Diese Informationen dienen im Wesentlichen der Transparenz zu Inhalten und Rahmenbedingungen des Standardisierungsvorhabens und sollen die Wiederverwendung fördern.

K-6 `MUSS`: Anzeige der Entwicklungsabsicht

Der Beginn der Entwicklung eines XÖV-Standards muss der Öffentlichkeit so früh wie möglich durch Angabe der Metadaten des Standards im XRepository angezeigt werden. Bei Bedarf können ergänzende Informationen zum Standard mittels weiterer im XRepository bereitgestellter Dokumente zur Verfügung gestellt werden.

Begründung: Redundante Entwicklungen für dieselben fachlichen Anforderungen sollen vermieden und eine Beteiligung weiterer Stakeholder ermöglicht werden.

Prüfgrundlage: Im XRepository bereitgestellte Informationen zum Standard

Prüfinhalt: Metadaten zum Standard liegen vollständig vor

K-7 `MUSS`: Informationen zum Status des Standards

Die für die Entwicklung und die Pflege des XÖV-Standards zuständige Stelle (Organisationseinheit der öffentlichen Verwaltung) muss die Metadaten des Standards im XÖV-Fachmodell des Standards und im XRepository pflegen und aktuell halten.

Begründung: Schaffen von Transparenz hinsichtlich der XÖV-Standards. Redundante Entwicklungen für denselben fachlichen Sachverhalt sollen vermieden und Synergien ermöglicht werden.

Prüfgrundlage: Im XRepository verfügbare Metadaten des Standards und seiner Version

Prüfinhalt: Die Metadaten des Standards und seiner Version sind aktuell und regelkonform

3.1.3. Wiederverwendung der XÖV-Bausteine

Die Nutzung der XÖV-Bausteine in XÖV-Standards unterstützt die standardübergreifende Interoperabilität und stellt damit einen zentralen Aspekt der XÖV-Konformität dar.

K-16 `SOLL`: Nutzung der Bausteine der XÖV-Bibliothek

Bei fachlicher Eignung sollen XÖV-Standards die mit der XÖV-Bibliothek herausgegebenen Bausteine anstelle eigener Entwicklungen nutzen. Hierzu ist die in Kapitel 9, dargelegte Methodik anzuwenden.

Begründung: Die gemeinschaftliche Nutzung von Bausteinen verbessert die Interoperabilität und erleichtert die Implementierung.

Prüfgrundlage: Im XRepository bereitgestelltes XÖV-Fachmodell^[3] und Dokument Zertifizierungsrelevante Begründungen

Prüfinhalt: Bausteine und weitere Datenstrukturen des Standards; Begründung eventueller Abweichungen

K-13 `SOLL`: Nutzung von Codelisten

Bei fachlicher, organisatorischer und rechtlicher Eignung soll eine im XRepository bereitgestellte Codeliste, der in Abschnitt 9.4, “Nutzung von Codelisten” beschriebenen Methodik folgend, wiederverwendet und damit der Entwicklung einer neuen Codeliste vorgezogen werden.

Begründung: Verbesserung der Interoperabilität durch einheitliche Verwendung von Codes.

Prüfgrundlage: Im XRepository bereitgestelltes XÖV-Fachmodell^[3] und Dokument Zertifizierungsrelevante Begründungen

Prüfinhalt: Codelisten nutzende Datenstrukturen des Standards; Begründung eventueller Abweichungen

3.1.4. Technische Kriterien

Die technischen Kriterien der XÖV-Konformität beziehen sich auf das XÖV-Fachmodell und seine Abbildung in XSD-Schemas. Diese Kriterien sind durch die Verwendung der XÖV-Produktionsumgebung weitestgehend automatisiert überprüfbar.

K-8 `SOLL`: Modellierung der Prozesse

Die Prozesse, in deren Rahmen die durch den XÖV-Standard spezifizierten Nachrichten übermittelt werden, sollen unter Verwendung der UML-Notation als Aktivitätsdiagramme beschrieben werden. Bei der Beschreibung ist der Fokus auf die Aktivitäten und Abläufe, die zum Erstellen, Übermitteln und Verarbeiten der Nachrichten führen, zu setzen.

Begründung: Das gemeinsame Verständnis der Prozesse ist wichtig für die Spezifikation konkreter Nachrichten. Die Dokumentation der Prozesse im Spezifikationsdokument des Standards stellt eine wichtige Grundlage für die Umsetzung der korrekten Abläufe, Prüfungen und Entscheidungen sowie einer kontextspezifischen Befüllung von Nachrichten in einem IT-Verfahren dar. UML ist eine anerkannte Notation für die Modellierung von Prozessen.

Prüfgrundlage: Im XRepository bereitgestelltes Spezifikationsdokument des Standards und Dokument Zertifizierungsrelevante Begründungen

Prüfinhalt: UML-Aktivitätsdiagramme; Begründung eventueller Abweichungen

K-9 `MUSS`: Modellierung der Datenstrukturen

Die Modellierung der Datenstrukturen des XÖV-Standards muss in einem XÖV-Fachmodell unter Verwendung der XÖV-Modellierungssprache in der Notation classic oder lite erfolgen.

Begründung: Die XÖV-Modellierungssprache umfasst genau die für die Modellierung der Inhalte des XÖV-Fachmodells erforderlichen Sprachelemente und erlaubt damit eine zielgerichtete, einheitliche und wohldefinierte Entwicklung. Sie bietet eine geeignete Abstraktion für die Beschreibung von Datenstrukturen und erlaubt eine integrierte Sicht auf die Bestandteile eines XÖV-Fachmodells. Die Verwendung der XÖV-Modellierungssprache ist eine Voraussetzung für die Verarbeitung durch die XÖV-Produktionsumgebung.

Prüfgrundlage: Im XRepository bereitgestelltes XÖV-Fachmodell^[3]

Prüfinhalt: Fehlerfreie Verarbeitung des XÖV-Fachmodells^[4] durch den XGenerator und die XÖV-Produktionsumgebung

K-10 `MUSS`: Einhaltung der XÖV-Namens- und Entwurfsregeln

XÖV-Namens- und Entwurfsregeln müssen entsprechend ihrer Verbindlichkeit bei der Spezifikation eins XÖV-Standards berücksichtigt werden. Das schließt die Verwendung der von der XÖV-Koordination veröffentlichten XÖV-Produktionsumgebung in der zum Zeitpunkt der Beantragung der Zertifizierung jeweils gültigen Version ein.

Begründung: Die Interoperabilität von XÖV-Standards soll bereits auf der Modellebene unterstützt werden. Die Anwendung der XÖV-Namens- und Entwurfsregeln leistet auf der einen Seite einen Beitrag zur korrekten Anwendung der XÖV-Modellierungssprache und stellt auf der anderen Seite die konkrete Umsetzung grundlegender XÖV-Prinzipien und -Methodik im XÖV-Fachmodell sicher.

Prüfgrundlage: Im XRepository bereitgestelltes XÖV-Fachmodell^[3]

Prüfinhalt: Validierung des XÖV-Fachmodells und Generierung der XSD-Schemas durch Anwendung der XÖV-Produktionsumgebung

K-14 `MUSS`: Erfolgreiche Verarbeitung des XÖV-Fachmodells durch die XÖV-Produktionsumgebung

Das XÖV-Fachmodell muss fehlerfrei durch die von der XÖV-Koordination herausgegebene XÖV-Produktionsumgebung in einer zum Zeitpunkt der Beantragung der Zertifizierung jeweils gültigen Version verarbeitet werden können. Dies beinhaltet die Prüfung der automatisiert auswertbaren XÖV-Regelungen und die fehlerfreie Erzeugung der XSD-Schemas.

Begründung: Die Qualitätsziele des XÖV-Standardisierungsrahmens können nur durch einen hohen Automatisierungsgrad bei Erzeugung und Qualitätssicherung der Bestandteile eines XÖV-Standards erreicht werden.

Prüfgrundlage: Im XRepository bereitgestelltes XÖV-Fachmodell^[3]

Prüfinhalt: Einhaltung der technisch implementierten XÖV-Regelungen

K-15 `SOLL`: Nutzung einer sicheren Infrastruktur für den elektronischen Datenaustausch

Ein XÖV-Standard soll zur Erfüllung der in dem jeweiligen fachlichen Kontext notwendigen Sicherheitsanforderungen die im Auftrag der öffentlichen Verwaltung und insbesondere des IT-Planungsrats betriebenen Lösungen in angemessenem Umfang berücksichtigen. Hierzu zählen unter anderem:

Sicherheitsinfrastruktur: Public Key Infrastructure der Verwaltung (PKI-1-Verwaltung),
Gesicherte Datenübermittlung: Online Services Computer Interface (OSCI-Transport) und
Adressierungsdienst und Kommunikationsinfrastruktur: Deutsches Verwaltungsdiensteverzeichnis DVDV.

Begründung: Die öffentliche Verwaltung entwickelt und betreibt Infrastrukturkomponenten, die sich an sicheren elektronischen Diensten (Secure Web Services) orientieren. Neben der dafür erforderlichen Standardisierung elektronischer Dienste auf fachlicher Ebene ist vor allem auch die Sicherheit bei der Inanspruchnahme und Erbringung der Dienste zu gewährleisten. Methodische und technische Grundlagen der fachlichen Standardisierung und der Infrastrukturkomponenten sind aufeinander abgestimmt. Die Wirtschaftlichkeit von Infrastrukturkomponenten ist umso höher, je größer die Zahl der Nutzenden ist. Aus diesem Grund und wegen der abgestimmten Weiterentwicklung fachlicher und sicherheitstechnischer Standards im Sinne sicherer elektronischer Dienste, empfehlen die KoSIT und das Bundesministerium des Innern (BMI) die angemessene Nutzung der von der öffentlichen Verwaltung entwickelten Infrastrukturkomponenten.

Prüfgrundlage: Im XRepository bereitgestellte Informationen zum Standard und Dokument Zertifizierungsrelevante Begründungen

Prüfinhalt: Metadaten und Spezifikationsdokument des Standards, ggf. weitere zum Standard bereitgestellte Dokumente mit Angaben zur Verwendung der sicheren Infrastruktur; Begründung eventueller Abweichungen

3.2. XÖV-Zertifizierung

Die XÖV-Zertifizierung bietet allen Vorhaben und Betreibenden die Möglichkeit, die Konformität ihres Standards in einer bestimmten Version zu den XÖV-Konformitätskriterien bestätigen zu lassen.

Mit der Vergabe eines XÖV-Zertifikats durch die XÖV-Koordination wird eine formale und technische Mindestqualität eines Standards bestätigt. Dies kann zur Sicherung der Qualität der Arbeitsergebnisse innerhalb des eigenen Vorhabens genutzt werden. Zudem soll die Zertifizierung insbesondere beim Rollout des XÖV-Standards unterstützen sowie Vertrauen bei den beteiligten Behörden, Herstellern von IT-Verfahren und anderen an der Datenübermittlung Beteiligten schaffen.

Der Zertifizierungsprozess kann durch den Betreiber eines Standards nach der Bereitstellung aller zertifizierungsrelevanten Dokumente über das XRepository erfolgen (siehe hierzu auch XRepository-Hilfe).

Zertifizierungsrelevante Dokumente sind das XÖV-Fachmodell^[3], die XSD-Schemas und das Spezifikationsdokument zu einer Version des Standards. Darüber hinaus müssen das Pflegekonzept des Standards sowie ein Dokument mit den zertifizierungsrelevanten Begründungen zur Beantragung der Zertifizierung bereitgestellt werden.

Die Prüfung der Konformität einer Version eines Standards zu den für XÖV-Standards geltenden XÖV-Regelungen, insbesondere der Namens- und Entwurfsregeln (siehe Kapitel 6, ), erfolgt zu einem erheblichen Teil automatisiert anhand des XÖV-Fachmodells. Die hierfür eingesetzte Prüfumgebung ist Bestandteil der XÖV-Produktionsumgebung und steht somit jedem Vorhaben bereits in der Entwicklungsphase des Standards vollständig zur Verfügung.

Eine Übersicht der aktuell gültigen XÖV-Konfigurationen ist auf XÖV docs unter Gültige-XÖV-Konfigurationen verfügbar.

Teil II: Entwicklung eines XÖV-Standards

4. XÖV-Entwicklungsprozess

Ein XÖV-Standard kann im Wesentlichen als eine explizite, formale und detaillierte Spezifikation eines oder mehrerer Datenübermittlungsszenarien verstanden werden. Das XÖV-Fachmodell ist das zentrale Informationsmodell eines XÖV-Standards. Es enthält neben den Informationen zu den unterschiedlichen Aspekten einer oder mehrerer Datenübermittlungen alle administrativen Informationen zum Standard.

In den folgenden Abschnitten werden die Schritte beschrieben, die sowohl Neuvorhaben als auch bestehende XÖV-Standards durchlaufen, um ein XÖV-Fachmodell von Grund auf neu zu entwickeln oder ein bestehendes fortzuschreiben.

Im Abschnitt 4.1, “Entwurfsphase” werden die Schritte zur Erfassung und Abbildung aller initial relevanten Informationen zum Standard und zu den geplanten Datenübermittlungsszenarien für Neu- und Bestandsvorhaben beschrieben.

Im Abschnitt 4.2, “Spezifikationsphase” werden die Schritte zur Konkretisierung von Anforderungen, Modellierung von Informationen im XÖV-Fachmodell und Dokumentation von Inhalten beschrieben.

Der Abschnitt 4.3, “Produktionsphase” beschreibt die Grundlagen zur Produktion. Hierbei werden sowohl die verwendeten XÖV-Produkte als auch die einzelnen Schritte zur Erstellung der Bestandteile eines XÖV-Standards eines XÖV-Standards dargestellt.

4.1. Entwurfsphase

Die Entwurfsphase ist geprägt durch den kollaborativen Prozess der Erhebung der administrativen Informationen und der Informationen zu den Datenübermittlungsszenarien eines XÖV-Standards. Die Dokumentation der in einem solchen Prozess erhobenen Informationen sollte aus Effizienzgründen weitestgehend schon in den durch den XÖV-Standardisierungsrahmen vorgesehenen Strukturen und Formaten erfolgen.

Administrative Informationen wie beispielsweise der Name, die Kennung oder die Beschreibung eines Standards werden im Kontext des XÖV-Standardisierungsrahmens als Metadaten bezeichnet. Sie werden im XÖV-Fachmodell abgebildet und mit der Bereitstellung des Modells im XRepository automatisiert ausgewertet und zum Standard bzw. der konkreten Version eines Standards angezeigt. Eine detaillierte Darstellung der einzelnen Metadaten, ihrer Semantik und der zugehörigen Regelungen zu Verwendung, Struktur und Format finden sich in Anhang C, .

Die Identifikation und Beschreibung der Datenübermittlungsszenarien sowie die Erhebung der fachlichen Anforderungen an die in den Szenarien geplanten Datenübermittlungen erfolgt in der Regel in einem moderierten Prozess. Hierbei werden die rechtlichen, organisatorischen, semantischen und technischen Rahmenbedingungen von den Beteiligten erfasst, konsolidiert und dokumentiert.

Ein solcher Erhebungsprozess ist stets an der individuellen Ausgangssituation und Zielsetzung eines Vorhabens auszurichten und wird in den Details stets unterschiedlich ausgeprägt sein. Ein allgemeiner Erfolgsfaktor ist dabei die frühzeitige Abstimmung und Etablierung einheitlicher Begrifflichkeiten unter allen Beteiligten.

Als weiterer Erfolgsfaktor gilt ein einheitliches Vorgehen bei der Konkretisierung und Ausgestaltung der Anwendungsfälle, die zur Datenübermittlung führen. Hierzu gehört die Abbildung und Beschreibung der Prozesse, in deren Rahmen Daten übermittelt werden, sowie die Festlegung des jeweils benötigten Umfangs, der Struktur und der Form der zu übermittelnden Daten.

Unter anderem aus diesem Grund sieht der XÖV-Standardisierungsrahmen für die Dokumentation der Ergebnisse der Entwurfsphase UML-Notationen für Anwendungsfall-, Aktivitäts- und Klassendiagramme vor. Eine einheitliche Notation in dieser Art erleichtert zudem die Vergleichbarkeit und Wiederverwendbarkeit der Komponenten bereits praxiserprobter XÖV-Lösungen.

Die UML-Notation für Anwendungsfalldiagramme unterstützt eine schnell erfassbare und unmissverständliche Darstellung eines Anwendungsfalls für die Datenübermittlung. Neben der Benennung und Beschreibung des Anwendungsfalls werden in dieser Darstellung auch alle beteiligten Akteure benannt und beschrieben. Somit können Anwendungsfalldiagramme die verschiedenen Bereiche, in denen Partner im Rahmen eines Datenübermittlungsszenarios kommunizieren, veranschaulichen.

Auf der Grundlage dieser Festlegungen können ein oder mehrere Aktivitätsdiagramme erstellt werden, die dokumentieren, unter welchen Bedingungen Daten von wem an wen übermittelt werden. Dabei werden die Prozessschritte (Aktivitäten) aufgeführt, die zur Übermittlung der Daten in Form einer Nachricht führen und die Aktivitäten, die nach Eingang der Nachricht ablaufen.

Im Zuge der Abstimmung der Datenübermittlungsprozesse können die erforderlichen fachlichen, administrativen und prozesssteuernden Inhalte der zu übermittelnden Nachrichten sukzessive entwickelt werden.

Ob und in welchem Umfang die Dokumentation der Ergebnisse bereits in der Entwurfsphase in einem zentralen Fachmodell erfolgen kann, wird insbesondere durch die Wahl der XÖV-Notation (siehe hierzu Kapitel 5, ) und die zugehörige Wahl eines Modellierungswerkzeugs zur Erstellung und Pflege des XÖV-Fachmodells bestimmt.

4.2. Spezifikationsphase

In der Spezifikationsphase werden die in der Entwurfsphase erhobenen Information in einem XÖV-konformen XÖV-Fachmodell abgebildet und konkretisiert.

Ziel dieser Phase ist es, alle aus technischer und dokumentatorischer Sicht relevanten Informationen zu den Datenübermittlungsszenarien und den Metadaten eines Standards zentral, einheitlich und konsistent sowie in einer für die automatisierte Verarbeitung erforderlichen Form zu spezifizieren. Unter dem Begriff Spezifikation werden hier insbesondere die Aufgabenbereiche Konkretisierung von Anforderungen, Modellierung und Dokumentation zusammengefasst.

Konkretisierung von Anforderungen: Die in der Entwurfsphase erhobenen fachlichen Anforderungen werden hinsichtlich ihrer technischen Umsetzung in die Bestandteile eines XÖV-Standards im Detail konkretisiert. Der Prozess der technischen Ausgestaltung geht in der Regel mit der Modellierung beispielsweise einer Nachricht des Standards im XÖV-Fachmodell einher.
Modellierung: Erhobene Informationen werden formal, eindeutig und durch die XÖV-Produktionsumgebung verarbeitbar gemäß den XÖV-Konformitätskriterien und XÖV-Namens- und Entwurfsregeln in dem XÖV-Fachmodell und gemäß den Kriterien des Codelisten-Handbuchs in dem Codelisten-Fachmodell eines Standards abgebildet. Grundlage der Modellierung ist die XÖV-Modellierungssprache und einer zugehörigen XÖV-Notationen.
Dokumentation: Unter diesem Aufgabenbereich sind alle Tätigkeiten zusammengefasst, die zur Erstellung der Dokumentationsbestandteile eines XÖV-Standards erforderlich sind. Im Rahmen der Modellierung werden alle modellierten Objekte vollständig im XÖV-Fachmodell dokumentiert. Die in der Produktionsphase aus dem XÖV-Fachmodell erzeugten technische Bestandteile des Spezifikationsdokuments werden zur Erstellung eines Spezifikationsdokuments um manuell erstellte Teildokumente mit zusätzlichen Informationen ergänzt. Neben dem obligatorischen Spezifikationsdokument werden weitere Dokumente zum Standard (z. B. Pflegekonzept) oder zu einer Versionen des Standards erstellt.

In der Spezifikationsphase eines Standards werden somit neben den rein fachlichen insbesondere auch die Entscheidungen zur technischen Umsetzung getroffen.

4.3. Produktionsphase

In der Produktionsphase erfolgt mittels XÖV-Produkten eine automatisierte Überprüfung und Übersetzung des XÖV-Fachmodells sowie der technischen Bestandteile des Spezifikationsdokuments in die Bestandteile eines XÖV-Standards. Die Aktivitäten zur Produktion können dementsprechend in eine Prüfphase und eine Übersetzungsphase eingeteilt werden. Sie finden während und nach Abschluss der Modellierung zur Kontrolle der Qualität von Zwischenergebnissen statt.

Die Produktion wird konkret mit der XÖV-Produktionsumgebung und durch den XGenerator ausgeführt. Die XÖV-Produktionsumgebung (kurz XÖV-PU) stellt die zu einer gültigen XÖV-Konfiguration gehörenden Prüf- und Übersetzungsanweisungen als eine Anwendung für den XGenerator bereit. Der XGenerator liest diese automatisiert ein und wendet sie auf ein gegebenes XÖV-Fachmodell an. Als Ergebnis liegt auf der einen Seite ein Prüfprotokoll vor, welches über die Einhaltung der Prüfanweisungen sowie die Gründe für ihre Verletzung Aufschluss gibt. Auf der anderen liegen im Falle eines fehlerfreien XÖV-Fachmodells aus diesem generierte Bestandteile des Standards vor sowie technische Bestandteile des Spezifikationsdokuments. Letztere können unter Hinzuziehen weiterer manuell erstellter Teildokumente in ein Gesamtdokument zusammengeführt und mittels Werkzeugen der XÖV-PU in ein Spezifikationsdokument überführt werden.

4.3.1. XÖV-Produktionsumgebung

Die XÖV-PU ist die technische Grundlage für die Produktion. Mit ihr stehen einer bestimmten XÖV-Konfiguration entsprechende Komponenten zur Prüfung und Übersetzung eines XÖV-Fachmodells bereit. Diese Komponenten liegen gebündelt in einer oder mehreren Anwendungen für den XGenerator vor und bestimmen die konkreten Aktivitäten des XGenerators bei der Verarbeitung eines XÖV-Fachmodells.

Die Komponenten der XÖV-PU stellen auf der einen Seite Prüfanweisungen dar, welche die XÖV-Namens- und Entwurfsregeln weitestgehend technisch abbilden und automatisiert auswertbar machen. Auf der anderen Seite stellen die Komponenten Übersetzungsanweisungen dar, die eine automatisierte Erstellung der Bestandteile eines XÖV-Standards in der Form von XSD-Schemas, XÖV-Geschäftsregeln in Schematron, ggf. Codelisten im Genericode-Format und WSDL-Dateien zur Beschreibung der Dienste eines Standards ermöglichen. Darüber hinaus stehen Übersetzungsanweisungen für die Generierung der zentralen technischen Bestandteile des Spezifikationsdokuments zur Verfügung.

XÖV-PU Editionen

Die XÖV-PU wird als XÖV-Produkt über die XÖV docs in unterschiedlichen Editionen für jede XÖV-seitig unterstützte Umgebung bereitgestellt. Aktuell sind somit die folgenden Editionen verfügbar:

classic (modern) für das UML-Modellierungswerkzeug MagicDraw
classic (modern) für das UML-Modellierungswerkzeug Papyrus
lite für XML-Modellierungswerkzeuge oder zur Verwendung in der XÖV suite

Für Neuvorhaben wird die jeweils aktuellste XÖV-PU im sogenannten XÖV-Starterpaket mit bereitgestellt.

4.3.2. Verzeichnisstruktur in der XÖV-Produktionsumgebung

Die Spezifikation eines Standards erfolgt in der XÖV-PU. Die Umgebung gibt je Ausprägung (XÖV classic oder XÖV lite) eine bestimmte Verzeichnisstruktur vor, die ein passendes Zusammenspiel der Modellierungswerkzeuge mit der XÖV-Produktionsumgebung und dem XGenerator erlaubt.

Die Verzeichnisstruktur in der ein Standard spezifiziert und produziert wird, ist wie in der folgenden Abbildung dargestellt aufgebaut.

Verzeichnisstruktur eines XÖV-Standards

└───xbeispiel
    │   generate_documentation.bat (Bestandteil der XÖV-PU)
    │   XBeispiel.xgen-project
    │
    ├───build
    │   ├───docbook
    │   ├───lite-model (nur bei XÖV-Notation classic)
    │   ├───plantuml
    │   ├───sch
    │   ├───wsdl
    │   └───xsd
    |
    ├───codelists
    |
    ├───docbookzubehoer (Bestandteil der XÖV-PU)
    |
    ├───model (konkrete Ausgestaltung siehe Beschreibung)
    │   │   ...
    │   └───externeModelle
    │           XOEV-Bibliothek.xml
    |           ...
    │
    ├───src
    │   │   spezifikation.xml
    │   │   ....xml
    |
    └───xgen-applications (Bestandteil der XÖV-PU)
        ├───xoev-lite
        └───xoev-profil (nur bei XÖV-Notation classic)

Verzeichnis bei XÖV-Notation `lite`

In der lite Ausprägung ist das Verzeichnis, in dem ein Standard spezifiziert und produziert wird, wie folgt aufgebaut:

build: (Verzeichnis): Das Verzeichnis wird automatisch vom XGenerator erstellt. Es enthält das Ergebnis der Prüfung (xgenerator-log.xml) und die Ergebnisse der Übersetzung des XÖV-Fachmodells in Unterverzeichnissen strukturiert.
codelists: (Verzeichnis): Das Verzeichnis enthält die eigenen und externen im Standard genutzten Codelisten im Genericode-Format (für Nutzungsart 1 und 2 die konkret genutzte Version; für Nutzungsart 3 die jüngste Version). Die hier abgelegten Codelisten werden zur Prüfung sowie zur Übernahme erforderlicher Codelisten-Metadaten und -Daten in die Bestandteile des Standards benötigt.
docbookzubehoer: (Verzeichnis): Das Verzeichnis enthält Mittel zur Erzeugung eines Spezifikationsdokuments (PDF) aus einem DocBook-Gesamtdokument.
model: (Verzeichnis): Das Verzeichnis enthält das eigene XÖV-Fachmodell in der lite Notation und die genutzten externen Modelle in einem oder mehreren Unterverzeichnissen.
src: (Verzeichnis): Das Verzeichnis enthält die handgeschriebenen Bestandteile des Spezifikationsdokuments, die zusammen mit den generierten technischen Bestandteilen in ein vollständiges Spezifikationsdokument überführt werden.
xgen-applications: (Verzeichnis): Das Verzeichnis enthält die XGenerator-Anwendungen, zu denen auf jeden Fall die mit der XÖV-PU bereitgestellten Anwendungen gehören. XBeispiel.xgen-project*: Diese Datei wird vom XGenerator initial angelegt und speichert die in der XGenerator-GUI getroffenen Einstellungen.
generate_documentation.bat: (Datei, optional): Bei dieser Datei handelt es sich um ein Skript zur beispielhaften Überführung eines DocBook-Gesamtdokuments in ein PDF-Gesamtdokument.

Verzeichnis bei XÖV-Notation `classic`

In der classic Ausprägung ist das Verzeichnis, in dem ein Standard spezifiziert und produziert wird, wie folgt aufgebaut:

build: (Verzeichnis): Das Verzeichnis wird automatisch vom XGenerator erstellt. Es enthält das Ergebnis der Prüfung (xgenerator-log.xml) und die Ergebnisse der Übersetzung des XÖV-Fachmodells in Unterverzeichnissen strukturiert.
codelists: (Verzeichnis): Das Verzeichnis enthält die externen im Standard genutzten Codelisten im Genericode-Format (für Nutzungsart 1 und 2 die konkret genutzte Version; für Nutzungsart 3 die jüngste Version). Die Codelisten werden zur Prüfung sowie zur Übernahme erforderlicher Codelisten-Metadaten und -Daten in die Bestandteile des Standards benötigt. Die eigenen Codelisten werden vom XGenerator in das Verzeichnis build/genericode generiert.
docbookzubehoer: (Verzeichnis): Das Verzeichnis enthält Mittel zur Erzeugung eines Spezifikationsdokuments (PDF) aus dem DocBook-Gesamtdokument.
model: (Verzeichnis): Das Verzeichnis enthält das eigene und die genutzten externen XÖV-Fachmodelle in der classic Notation, d. h. im Format des genutzten UML-Modellierungswerkzeugs, sowie die externen Modelle zusätzlich in der lite Notation. Darüber hinaus enthält das Verzeichnis die mit der XÖV-Produktionsumgebung gelieferten UML-Profile und -Modelle, welche die Modellierung eines XÖV-Fachmodells in der classic Notation ermöglichen.
src: (Verzeichnis): Das Verzeichnis enthält die handgeschrieben, technischen Bestandteile des Spezifikationsdokuments, die zusammen mit den generierten technischen Bestandteilen in ein vollständiges Spezifikationsdokument überführt werden.
xgen-applications: (Verzeichnis): Das Verzeichnis enthält die XGenerator-Anwendungen, zu denen auf jeden Fall die mit der XÖV-PU bereitgestellten Anwendungen mit dem Namen "xoev-lite" und "xoev-profil" gehören.
XBeispiel.xgen-project: (Datei): Diese Datei wird vom XGenerator initial angelegt und speichert die in der XGenerator-GUI getroffenen Einstellungen.
generate_documentation.bat: (Datei, optional): Bei dieser Datei handelt es sich um Skript zur beispielhaften Überführung der technischen Bestandteile des Spezifikationsdokuments der PDF-Generierung

Mit der Verwendung der XÖV-PU ist es für die Produktion von XÖV-Fachmodellen in der classic-Notation erforderlich, die genutzten externen Modelle zusätzlich in der lite-Notation im model-Verzeichnis bereitzustellen.

4.3.3. Ablauf des Produktionsprozesses

Der XGenerator ist im Produktionsprozess ein zentraler Akteur. Wenn dieser die Verarbeitung eines XÖV-Fachmodells beginnt, führt er folgende zentrale Schritte aus. Dabei wird zwischen dem Vorgehen bei Modellen in der lite und classic Notation unterschieden.

Produktionsprozess für `lite`

Bei einem XÖV-Fachmodell in der lite Notation geht der XGenerator wie folgt vor:

Er liest das XÖV-Fachmodell im lite-Format ein.
Er schemavalidiert das Modell gegenüber den grundlegenden Vorgaben der Modellierungssprache und stoppt bei Fehlern.
Sofern das XÖV-Fachmodell schemavalide ist, wendet er die XÖV-Prüfanweisungen an und informiert bei nicht eingehaltenen Empfehlungen, warnt bei nicht eingehaltenen SOLL-Regeln und bricht bei Nichteinhaltung von MUSS-Regeln mit einer Fehlermeldung ab. Dabei erläutert er das Problem und gibt Hinweise auf die Problemquelle.
Sofern keine Fehler vorliegen, übersetzt der XGenerator das XÖV-Fachmodell in XSD-Schemas, technische Bestandteile des Spezifikationsdokuments, Schematron (sofern XÖV-Geschäftsregeln modelliert sind) und WSDL-Dateien (sofern Dienste modelliert sind).

Produktionsprozess für `classic`

Bei einem XÖV-Fachmodell in der classic Notation geht der XGenerator wie folgt vor:

Er liest das XÖV-Fachmodell im classic-Format ein.
Er übersetzt das Modell zunächst in ein XÖV-Fachmodell in der lite Notation und stellt dabei unter Anwendung spezifischer Prüfanweisungen sicher, dass das classic-Modell in ein sprachlich korrektes und vollständiges lite-Modell überführt werden kann.
Sofern im classic-Modell eigene Codelisten modelliert sind, werden diese auf Einhaltung der Vorgaben des Codelisten-Handbuchs überprüft und daraufhin in genericode-Codelisten überführt.
Das aus dem classic-Modell erstellte lite-Modell wird im Anschluss als solches wie oben beschrieben verarbeitet, d. h. begonnen mit dem Einlesen des Modells im lite-Format.

4.3.4. Erstellung eines Spezifikationsdokuments

Während ein Großteil der vom XGenerator erzeugten Bestandteile des Standards (insbesondere die XSD-Schemas) nicht weiter bearbeitet werden dürfen, liegen die generierten technischen Bestandteile des Spezifikationsdokuments in einem Zwischenformat vor, welches grundsätzlich in ein beliebiges Endformat überführt werden kann.

Der Prozess zur Produktion von Ausgabeformaten wie PDF und HTML aus Quelldokumenten im DocBook-Format ist weit verbreitet und wird durch eine Reihe frei verfügbarer Werkzeuge unterstützt. Die XÖV-PU bringt Werkzeuge für das Quellformat OASIS DocBook mit. Darüber hinaus wird ein beispielhaftes Skript zur Veranschaulichung der Anwendung dieser Werkzeuge mitgeliefert.

5. Modellierung eines XÖV-Fachmodells

Der XÖV-Standardisierungsrahmen basiert auf dem methodischen Ansatz der modellgetriebenen Entwicklung. Alle Informationen, die für die automatisierte Erstellung der Bestandteile eines XÖV-Standards durch den XGenerator auf Basis der XÖV-Produktionsumgebung erforderlich sind, werden bei diesem Ansatz im Rahmen der Spezifikationsphase in das sogenannte XÖV-Fachmodell des Standards abgebildet. Die Modellierung eines XÖV-Fachmodells mit den Mitteln der XÖV-Modellierungssprache, auch als XÖV-Modellierung bezeichnet, ist somit zentraler Bestandteil der Spezifikation von Informationen eines Standards.

Mit den folgenden Abschnitten werden zunächst die XÖV-Modellierungssprache und zugehörige XÖV-Notationen eingeführt. Darauf basierend wird der grundlegende Aufbau eines XÖV-Fachmodells anhand der Sprachelemente der XÖV-Modellierungssprache und zugehöriger beispielhafter Umsetzungen in den Notationen lite und classic erläutert.

5.1. XÖV-Modellierungssprache und Notationen

Die XÖV-Modellierungssprache wird zur Modellierung eines XÖV-Fachmodells genutzt und betrifft alle auf der Grundlage der XÖV-Produktionsumgebung verarbeitbaren Inhalte des Modells. Sie definiert die zur XÖV-Modellierung erforderlichen Sprachelemente und zugehörige Regelungen. Beispielhaft sollen hier die Sprachelemente Metadaten, Nachricht, XSD-Schema und Datentyp genannt werden, mit denen die Metadaten, Nachrichten, XSD-Schemas und Datentypen eines Standards spezifiziert werden. Eine mit der XÖV-Modellierungssprache einhergehende Grammatik definiert dazu die Regeln und Strukturen, die festlegen, wie diese Sprachelemente in einem XÖV-Fachmodell kombiniert werden können.

Die letztendliche Umsetzung dieser zunächst abstrakten Sprachelemente und Regeln erfolgt mittels XÖV-Notationen. Diese definieren die konkrete grafische oder textuelle Abbildung der XÖV-Sprachelemente beispielsweise zur Angabe der Metadaten eines Standards in einem XÖV-Fachmodell.

Mit den XÖV-Notationen classic und lite stehen zwei alternative, gleichwertige Notationen der XÖV-Modellierungssprache zur Verfügung. Beide Notationen setzen gleichermaßen und vollumfänglich die Sprachelemente und Grammatik der XÖV-Modellierungssprache um. Auch werden XÖV-Fachmodelle der beiden Notationen im selben Umfang durch die XÖV-Produkte des XÖV-Standardisierungsrahmens unterstützt. Beispiel 1, “Datentyp in XÖV-Notationen” zeigt beispielhaft die Spezifikation eines Datentyps in classic und lite.

Beispiel 1. Datentyp in XÖV-Notationen

classic

lite

classic

<datentyp name="TeilbekanntesDatum" gruppe.art="choice">
  <beschreibung>...</beschreibung>
  <eigenschaft name="jahrMonatTag" typ="xida:Tagesdatum">
    <beschreibung>...</beschreibung>
  </eigenschaft>
  <eigenschaft name="jahrMonat" typ="xida:JahrMonat">
    <beschreibung>...</beschreibung>
  </eigenschaft>
  <eigenschaft name="jahr" typ="xida:Jahr">
    <beschreibung>...</beschreibung>
  </eigenschaft>
</datentyp>

Die Unterschiede der Notationen liegen insbesondere in der zu nutzenden Repräsentationsform (UML oder XML) sowie in den einsetzbaren Modellierungswerkzeugen.

Mit dem Beginn der Spezifikationsphase müssen sich Neuvorhaben die Frage beantworten, welche XÖV-Notation und welches Modellierungswerkzeug zur Erstellung und Fortschreibung des XÖV-Fachmodells genutzt werden soll. Davon ausgehend kann anschließend die Frage nach weiteren erforderlichen Bestandteilen einer Arbeitsumgebung beantwortet werden, in der die Entwicklung und Produktion der Bestandteile eines XÖV-Standards des Standards stattfinden soll.

Wenn Sie mit dieser Fragestellung konfrontiert sind und auch bei weiteren Fragen in diesem Kontext zögern Sie nicht, das Schulungs- und Beratungsangebot der XÖV-Koordination in Anspruch zu nehmen.

5.2. XÖV-Fachmodell

Das XÖV-Fachmodell ist das zentrale Informationsmodell (einer Version) eines XÖV-Standards. Es enthält neben den Metadaten zum Standard alle Informationen, die für die automatisierte Erstellung der obligatorischen Bestandteile eines XÖV-Standards durch den XGenerator auf Basis der XÖV-Produktionsumgebung erforderlich sind. Alle Inhalte eines XÖV-Fachmodells sind gemäß der XÖV-Modellierungssprache und einer zugehörigen XÖV-Notation spezifiziert. Die grundlegenden Sprachelemente der XÖV-Modellierungssprache zur Erstellung und Strukturierung eines XÖV-Fachmodells sowie ihre Beziehungen untereinander sind in der untenstehenden Abbildung in der Übersicht dargestellt.

Abbildung 3. Sprachelemente im Überblick

5.2.1. Sprachelement `XÖV-Fachmodell`

Das XÖV-Fachmodell enthält Angaben zur technischen Konfiguration, die Metadaten des Standards und seiner Version, Angaben zu den genutzten externen Modellen, sowie die inhaltlichen Bausteine des Standards, welche in (Schema-)Paketen strukturiert sind.

5.2.2. Sprachelement `Konfiguration`

Im Bereich der Konfiguration eines XÖV-Fachmodells können grundlegende technische Konfigurationen zum Standard und seiner Abbildung in XML-Schema vorgenommen werden. Dabei kann es sich zum Beispiel um einen für den Standard global einzusetzenden XML-Namensraum (namespace) und ein zugehöriges XML-Präfix (prefix) handeln. Viele globale Einstellungen können bei individuelleren Anforderungen auch auf lokaler Paket- bzw. Bausteinebene vorgenommen werden. So können beispielsweise die genannten Einstellungen für den Namensraum und das Präfix auch differenziert auf der Ebene der konkreten Schemapakete des Standards vorgenommen werden. Bei der Verarbeitung des XÖV-Fachmodells gelten die globalen Einstellungen, wenn keine konkreteren Angaben auf lokaler Ebene vorliegen.

Tabelle 3. Umsetzung der Sprachelemente zu `Konfiguration`
`classic`	UML-Modell mit UML-Stereotyp `xsdModel` und dazugehörige Stereotyp-Eigenschaften
`lite`	XML-Element `konfiguration.xoev-fachmodell` und dazugehörige Kindelemente und -attribute

In den folgenden Tabellen wird auf den Zusatz "UML-" und "XML-" verzichtet, da im Kontext der Notation classic stets UML-Komponenten und in der Notation lite stets XML-Komponenten angesprochen sind. Zudem wird in den Tabelle darauf verzichtet, auf die zugehörigen Stereotyp-Eigenschaften und XML-Kindelemente und -attribute hinzuweisen.

Da die Einstellungen, die im Bereich der Konfiguration vorgenommen werden können, ausschließlich die technische Ausgestaltung des Standards steuern, sind die zugehörigen Sprachelemente der XÖV-Modellierungssprache weitestgehend nach den zugehörigen technischen Konzepten benannt, die durch sie gesteuert werden. Eine Übersicht der Möglichkeiten zur Konfiguration eines XÖV-Fachmodells ist in Anhang A, dargestellt.

5.2.3. Sprachelement `Metadaten`

Die geregelte Fortschreibung und Nutzung von XÖV-Standards und Codelisten erfordert die systematische Bereitstellung von zugehörigen administrativen Informationen. Der XÖV-Standardisierungsrahmen regelt die Bereitstellung solcher Informationen in Form von strukturierten Metadaten. In Abbildung 4, “Sprachelemente zu sind die Sprachelemente zur Spezifikation der Metadaten eines Standards und seiner Version sowie ihre Häufigkeit im Überblick dargestellt.

Abbildung 4. Sprachelemente zu Metadaten

Die folgende Tabelle zeigt die Umsetzung der Sprachelemente zu den Metadaten eines Standards in den XÖV-Notationen.

Tabelle 4. Umsetzung der Sprachelemente zu `Metadaten`
`classic`	Modell mit Stereotypen `xoevStandard` und `xoevVersionStandard`
`lite`	Elemente `metadaten.standard` und `metadaten.versionStandard`

Eine beispielhafte Darstellung der Metadaten des Standards XBau und seiner Version 2.4 ist in der untenstehenden Abbildung gegeben.

Beispiel 2. Metadaten am Beispiel des Standards XBau (lite)

   <metadaten.standard>
      <nameLang>XBau - Standard für die Datenkommunikation der
        Bauaufsichtsbehörde</nameLang>
      <nameKurz>XBau</nameKurz>
      <nameTechnisch>xbau</nameTechnisch>
      <kennung>urn:xoev-de:bmk:standard:xbau</kennung>
      <beschreibung>XBau ist der XÖV-Standard für ...</beschreibung>
   </metadaten.standard>
   <metadaten.versionStandard>
      <version>2.4</version>
      <beschreibung>XBau Hochbau unterstützt ...</beschreibung>
      <versionXOEVHandbuch>4.0.0</versionXOEVHandbuch>
      <versionXOEVProduktionsumgebung>1.1.0</versionXOEVProduktionsumgebung>
      <nameModellierungswerkzeug>MagicDraw</nameModellierungswerkzeug>
      <versionModellierungswerkzeug>2021x</versionModellierungswerkzeug>
   </metadaten.versionStandard>

In Anhang C, ist eine detaillierte Darstellung der Sprachelemente, ihrer Strukturen und zugehöriger Regelungen gegeben, die zur Beschreibung eines Standards und seiner Versionen genutzt werden.

5.2.4. Sprachelement `Externes Modell`

Fast immer ist in einem XÖV-Standard die Nutzung externer Inhalte erforderlich. Hierbei kann es sich um Inhalte anderer XÖV-Standards, oder der von der XÖV-Koordination herausgegebenen XÖV-Bibliothek handeln. Die benötigten externen Modelle werden im XÖV-Fachmodell angegeben und damit eingebunden. Auf diese Weise kann auf deren Bausteine direkt zugegriffen werden, zum Beispiel auf die in der XÖV-Bibliothek angebotenen XÖV-Bausteine.

Die Einbindung externer Inhalte bietet darüber hinaus auch die Möglichkeit zur Modularisierung des eigenen Standards. So können beispielsweise einzelne Bereiche in eigene XÖV-Fachmodelle ausgegliedert und zur Nutzung wieder eingebunden werden. Dieser Ansatz wird in der Praxis beispielsweise genutzt, um die grundlegenden Inhalte eines Standards in einem Basismodul zu kapseln und dieses in eine Reihe von Fachmodulen des Standards einzubinden.

5.2.5. Sprachelement `Baustein`

Die Sprachelemente des Typs Baustein dienen der Spezifikation von Datenstrukturen und -formaten die im eigenen Standard oder darüber hinaus Anwendung finden können.

Typischerweise werden Datenstrukturen zu häufig genutzten Konzepten wie beispielsweise einer Anschrift (Straße, Hausnummer, Postfach etc.) oder dem Namen von natürlichen Personen (Vornamen, Anrede, Geburtsname, Familienname etc.) in Bausteinen abgebildet. Diese Bausteine können daraufhin mehrfach im eigenen Standard verwendet werden. Des Weiteren besteht die Möglichkeit, Bausteine aus anderen XÖV-Fachmodellen und XÖV-Bausteine im eigenen Standard zu nutzen. XÖV-Bausteine werden durch die XÖV-Koordination kuratiert mit der XÖV-Bibliothek zur Nutzung bereitgestellt.

Die mit dem XÖV-Standardisierungsrahmen angeboten Bausteine werden XÖV-Bausteine genannt. XÖV-Bausteine werden in der XÖV-Bibliothek zusammengefasst und zur Nachnutzung angeboten. Einzige Ausnahme bilden dabei die XÖV-Bausteine des Typs Codeliste. Sie werden ausschließlich über das XRepository zur Nachnutzung angeboten.

Abbildung 5, “Sprachelemente zu gibt einen Überblick über die Sprachelemente der XÖV-Modellierungssprache, die zur Spezifikation von Bausteinen genutzt werden können.

Abbildung 5. Sprachelemente zu Baustein

Die folgende Tabelle beschreibt die bestehenden Sprachelemente des Typs Baustein und deren Nutzung in den Notationen classic und lite.

Tabelle 5. Umsetzung der Sprachelemente zu `Baustein`
Nachricht
	`classic`	Klasse mit Stereotyp `xsdMessage`
	`lite`	Element `nachricht`
Datentyp (einfach / komplex)
/	`classic`	Klasse mit Stereotyp `xsdNamedType`
	`lite`	Element `datentyp`
Code-Datentyp
	`classic`	implizite Modellierung (Klasse mit Stereotyp `xsdNamedType` und Nutzungsbeziehung zu einer Codeliste, d. h. zu einer Klasse mit dem Stereotyp `xoevCodeliste` oder `xoevVersionCodeliste`)
	`lite`	Element `codeDatentyp`
Globale Eigenschaft (Element / Attribut)
/	`classic`	Klasse mit Stereotyp `xsdGlobalElement` oder `xsdGlobalAttribute`
	`lite`	Element `globaleEigenschaft` mit dem Attribut `xsdAttribute` gleich dem Wert `false` oder `true`
Globale Eigenschaftengruppe (Elemente / Attribute)
/	`classic`	Klasse mit Stereotyp `xsdGroup` und Eigenschaften, die XML-Elemente oder -Attribute repräsentieren
	`lite`	Element `globaleEigenschaftengruppe` mit Eigenschaften, die XML-Elemente oder -Attribute repräsentieren

Eine detailliertere Darstellung der Sprachelemente zur Spezifikation von Bausteinen ist in Kapitel 9, zum jeweiligen Bausteintyp gegeben.

5.2.6. Sprachelement `Codeliste`

Eine Codeliste ist eine Liste von Codes und der Beschreibung ihrer jeweiligen Bedeutung. Die Bedeutung von Codes kann dabei beispielsweise in Form von Namen (Augsburg, Bremen, München, etc.), Begrifflichkeiten (ledig, verheiratet, geschieden, etc.) oder Statusbeschreibungen (Antrag übermittelt, Antrag empfangen, Antrag unvollständig, etc.) vorliegen. In der Datenübermittlung werden Codelisten eingesetzt, um die für einen bestimmten Übermittlungskontext relevanten Sachverhalte eindeutig zu bezeichnen und in der erforderlichen Form zu beschreiben.

Codelisten werden gemäß den Regelungen des Codelisten-Handbuchs mittels der XÖV-Modellierungssprache in Codelisten-Fachmodellen spezifiziert. Eine vereinfachte Übersicht der hierfür benötigten Sprachelemente ist in der folgenden Abbildung gegeben.

Abbildung 6. Sprachelemente zu Codeliste

Alle Sprachelemente und zugehörige Regelungen zur Spezifikation von Codelisten(-Fachmodellen) sind mit dem Codelisten-Handbuch im Detail beschrieben.

Hinsichtlich der XÖV-Notation bestehen Unterschiede zu den weiteren Bausteinarten. Die Erstellung und Pflege eines Codelisten-Fachmodells kann in der Notation classic erfolgen sowie in der Notation des OASIS-Standards Genericode. In der Notation lite ist zwar die Nutzung von Codelisten (über Code-Datentypen) vorgesehen, jedoch nicht ihre inhaltliche Spezifikation.

Tabelle 6. Umsetzung der Sprachelemente zu `Codeliste`
`classic`	Klasse mit Stereotyp `xoevCodeliste` oder `xoevVersionCodeliste` (für Details siehe das Codelisten-Handbuch)
`lite`	nicht vorgesehen
`Genericode`	Genericode-Element `gc:CodeList` (für Details siehe das Codelisten-Handbuch)

Die Codelisten eines XÖV-Standards werden wie auch die durch die XÖV-Koordination herausgegebenen XÖV-Codelisten grundsätzlich im XRepository zur Nachnutzung bereitgestellt.

5.2.7. Sprachelemente `Paket` und `Schemapaket`

Die Strukturierung des XÖV-Fachmodells ermöglicht eine übersichtliche Ordnung der Inhalte nach unterschiedlichen Kriterien (z. B. fachlich, technisch und/oder organisatorisch) sowie eine geeignete Anordnung im Hinblick auf die Abbildung der Inhalte im Spezifikationsdokument des Standards. Zudem sind einzelne Strukturen und Strukturelemente erforderlich, um die ordnungsgemäße Verarbeitung des Modells durch die XÖV-Produktionsumgebung zu gewährleisten.

Beispiel 3, “Strukturen von XÖV-Fachmodellen” stellt beispielhaft Strukturen und Strukturelemente eines XÖV-Fachmodells in den XÖV-Notationen classic und lite dar.

Beispiel 3. Strukturen von XÖV-Fachmodellen

classic

lite

classic

lite

Die zur Bildung dieser Strukturen erforderlichen Sprachelemente der XÖV-Modellierungssprache basieren auf der Analogie des Paketbaums (auch Containment-Baum), wie er in vielen UML-Modellierungswerkzeugen genutzt wird.

Abbildung 7, “Sprachelemente zu stellt dar, wie bei der Modellierung die Sprachelemente Paket und Schemapaket genutzt werden können, um Strukturen zur Erstellung und Pflege der eigenen Inhalte im XÖV-Fachmodell anzulegen.

Abbildung 7. Sprachelemente zu Paket und Schemapaket

Mit dem Sprachelement Paket ist eine allgemeine Strukturierung eines XÖV-Fachmodells möglich. Mit dem Sprachelement Schemapaket wird eine XSD-Schema-Datei spezifiziert, deren Inhalte sich direkt aus den Inhalten des Schemapakets ergeben.

Die UML-basierte Notation classic ermöglicht die Strukturierung eines XÖV-Fachmodells direkt über die Anlage und Verschachtelung von UML-Paketen im Paketbaum des UML-Modells. Pakete können eine spezifische Bedeutung bekommen, wenn sie entsprechend benannt (z. B. Codelisten und Externe Modelle) oder mit bestimmten UML-Stereotypen (z. B. xoevStandard oder xsdSchema) ausgezeichnet werden.

Die Notation lite stellt für die allgemeine Strukturierung das Notationselement paket und für spezifische Paketarten eigene Modellierungselemente (z. B. externesModell und xsdSchema) bereit.

Tabelle 7. Umsetzung der Sprachelemente zu `Paket` und `Schemapaket`
Paket
	`classic`	Modell(paket) oder Paket
	`lite`	Element `paket`
Schemapaket
	`classic`	Paket mit Stereotyp `xsdSchema`
	`lite`	Element `xsdSchema`

5.3. Regelungen zur Ausgestaltung des XÖV-Fachmodells

Die technische Ausgestaltung eines XÖV-Standards unterliegt XÖV-spezifischen Namens- und Entwurfsregeln, welche die Einheitlichkeit, die technisch syntaktische und die semantische Interoperabilität von XÖV-Standards fördern sollen. Eine detaillierte Übersicht der XÖV-Namens- und Entwurfsregeln ist in Kapitel 6, gegeben.

Ergänzend dazu werden im XÖV-Handbuch mit den sogenannten XÖV Good Practices eine Reihe von Umsetzungshinweisen gegeben, die nicht zertifizierungsrelevant sind, aber als gute Beispiele aus der Praxis zur Orientierung genutzt werden können. Eine detaillierte Dokumentation aktueller Good Practises ist in Kapitel 7, gegeben.

6. XÖV-Namens- und Entwurfsregeln

Mit dem in Abschnitt 3.1.4.3, “K-10 beschriebenen Konformitätkriterium wird die Einhaltung der XÖV-Namens- und Entwurfsregeln (Naming and Design Rules, kurz NDR) gefordert.

6.1. NDR im Überblick

Die NDRs regeln hauptsächlich die technische Ausgestaltung eines XÖV-Standards und liegen, wie auch die XÖV-Konformitätskriterien, in den Verbindlichkeitsstufen SOLL und MUSS vor. Die Einhaltung der NDRs ist somit relevant für die Einstufung eines Standards als XÖV-Standard (siehe Kapitel 3, ).

Die Nutzung der XÖV-Produktionsumgebung stellt, sofern technisch möglich, die Einhaltung der NDRs sicher. Grundlage hierfür ist die Nutzung einer gültigen Konfiguration der XÖV-Produkte. Alle gültigen Konfigurationen sind auf XÖV docs unter Gültige XÖV-Konfigurationen veröffentlicht. Der Umfang der automatisierten Prüfung wird individuell für jede Regel ausgewiesen.

Tabelle 8. Übersicht der XÖV-Namens- und Entwurfsregeln
Nr.	Verbindlichkeit	Kurzbeschreibung
Strukturen und Inhalte
NDR-1	`MUSS`	Konsistente und vollständige Inhalte in XÖV-Fachmodell und den zentralen Bestandteilen des Standards
NDR-2	`MUSS`	Hauptstruktur eines XÖV-Fachmodells
NDR-3	`MUSS`	Nachrichten als globale Elemente
NDR-4	`SOLL`	Erlaubte Einbindungsarten für Codelisten
Namen für XML-Attribute, -Elemente und -Typen
NDR-11	`SOLL`	Erlaubte Zeichen für Namen
NDR-13	`SOLL`	Versionsübergreifend eindeutige Nachrichtennamen
Dokumentation
NDR-32	`MUSS`	Dokumentation der Metadaten des Standards
NDR-19	`SOLL`	Dokumentation in deutscher Sprache
Wiederverwendung
NDR-33	`MUSS`	Codelisten konform zu den Regelungen des Codelisten-Handbuchs
NDR-22	MUSS	Konsistenz von Codelisten in XÖV-Fachmodell und XRepository (nur für XÖV classic)
NDR-24	`SOLL`	Nutzung der XÖV-Basisnachricht
XML Schema-Konformität
NDR-28	`MUSS`	Valide W3C XSD-Schemas
Namensräume und Versionen
NDR-29	`MUSS`	Identifizierende Namensräume
NDR-30	`MUSS`	Versionierung der XSD-Schemas
NDR-31	`SOLL`	Namensräume mit Versionen

6.2. NDR im Detail

Die im Folgenden aufgeführten XÖV-NDR sind analog zur Kategorisierung innerhalb der Übersichtstabelle geordnet.

6.2.1. Strukturen und Inhalte

Ein einheitlicher Aufbau und die Nutzung einheitlicher Strukturen im Rahmen eines XÖV-Fachmodells sind auf der einen Seite eine Voraussetzung für die XÖV-spezifische Produktion eines XÖV-Standards. Auf der anderen Seite fördern sie die Interoperabilität von XÖV-Standards und erleichtern darüber hinaus den inhaltlichen Einstieg in fremde XÖV-Standards.

Darüber hinaus stellen Konsistenz und Vollständigkeit zwischen den Inhalten des XÖV-Fachmodells und den daraus abgeleiteten Bestandteilen des Standards eine zwingende Voraussetzung für den erfolgreichen Einsatz eines XÖV-Standards dar.

NDR-1 `MUSS`: Konsistente und vollständige Inhalte in XÖV-Fachmodell und den zentralen Bestandteilen des Standards

Die aus dem XÖV-Fachmodell erzeugten Bestandteile des Standards müssen hinsichtlich der sie betreffenden Inhalte des XÖV-Fachmodells vollständig und konsistent sein.

Erläuterung: Das XÖV-Fachmodell stellt das zentrale Informationsmodell eines XÖV-Standards dar, aus dem die zentralen Bestandteile des Standards mittels der XÖV-Produktionsumgebung automatisiert erzeugt werden. Die eingesetzte XÖV-Produktionsumgebung muss einer gültigen XÖV-Konfiguration entsprechen. Damit ist eine eindeutige und korrekte Übersetzung der Inhalte des XÖV-Fachmodells in die Bestandteile des Standards gewährleistet. Die erzeugten Bestandteile dürfen nicht manuell angepasst werden, da hierdurch Inkonsistenzen und Unvollständigkeiten zwischen den Bestandteilen des Standards hervorgerufen werden.

Begründung: Eine einheitliche Übersetzung eines XÖV-Fachmodells in die zentralen Bestandteile eines Standards ist die Grundlage für interoperable XÖV-Standards. Sie gewährleistet eine nachvollziehbare Spezifikation, da alle Inhalte und Strukturen eines XÖV-Fachmodells ohne Ausnahme auf ihre Repräsentation in den verschiedenen Bestandteilen (z. B. den XSD-Schemas) schließen lassen.

Prüfung: Die Einhaltung dieser Regel wird durch die Verwendung der XÖV-Produktionsumgebung in einer aktuell gültigen Version sichergestellt.

NDR-2 `MUSS`: Hauptstruktur eines XÖV-Fachmodells

Das XÖV-Fachmodell eines XÖV-Standards muss auf oberster Ebene einer vordefinierten Struktur folgen, welche die Inhalte des eigenen Standards von externen, in den XÖV-Standard eingebundenen Inhalten unterscheidet.

Erläuterung: Das XÖV-Fachmodell eines XÖV-Standards trennt auf oberster Ebene externe und eigene Inhalte.

Tabelle 9. NDR-2: Hauptstruktur eines XÖV-Fachmodells
Inhalte des Standards
classic	Im classic-Modell eines XÖV-Standards muss genau ein UML-Paket existieren, dass mit dem Stereotyp `xsdXModel` ausgezeichnet ist. Alle eigenen Inhalte die zur automatisierten Erzeugung der Bestandteile des Standards herangezogen werden, müssen sich unterhalb dieser Paketstruktur befinden.
lite	Im Unterschied zur classic-Umgebung sind alle Inhalte eines lite-Modells unterhalb des Root-Elements `xoev-fachmodell` Bestandteile des eigenen Standards, solange sie nicht explizit als externer Inhalt ausgezeichnet sind.
Externe Modelle
classic	Im classic-Modell eines XÖV-Standards muss genau ein UML-Paket mit dem Namen `Externe Modelle` existieren. Unterhalb dieser Paketstruktur müssen die im eigenen Standard genutzten Modelle anderer Standards und der XÖV-Bibliothek abgelegt werden.
lite	Die Einbindung externer Modelle zur Nachnutzung im eigenen XÖV-Standard erfolgt mittels des XML-Elements `externesModell`. Die so eingebundenen Modelle müssen im Dateisystem innerhalb des `model`-Verzeichnisses vorliegen, in dem sich die Modelldatei des nutzenden Standards befindet (in der Regel in `model/externeModelle`).
Beispiele
classic
lite

Begründung: Die Abgrenzung der originären Inhalte eines XÖV-Standards von weiteren, wiederverwendeten Inhalten ermöglicht die automatisierte Identifizierung der im Rahmen des XÖV-Produktionsprozesses zu prüfenden und zu erzeugenden Bestandteile des Standards.

Prüfung: Die Einhaltung dieser Regel wird durch die Verwendung der XÖV-Produktionsumgebung in einer aktuell gültigen Version sichergestellt.

NDR-3 `MUSS`: Nachrichten als globale Elemente

Nachrichten eines XÖV-Standards müssen globale XML-Elemente sein.

Erläuterung: Nachrichten eines XÖV-Standards müssen globale XML-Elemente darstellen. Mit der Verwendung der aktuellen XÖV-Produktionsumgebung und des Bausteins Nachricht zur Modellierung von Nachrichten erfolgt die Umsetzung automatisiert.

Begründung: Im Kontext eines XÖV-Standards stellen elektronisch übermittelte Nachrichten letztendlich XML-Dokumente mit konkreten Daten dar. Die strukturellen und inhaltlichen Vorgaben für ein solches XML-Dokument basieren auf einem globalen XML-Element, welches im Rahmen der XSD-Schemas des XÖV-Standards als Nachricht spezifiziert ist.

Prüfung: Die Einhaltung dieser Regel wird durch die Verwendung der XÖV-Produktionsumgebung in einer aktuell gültigen Version sichergestellt.

NDR-4 `SOLL`: Erlaubte Einbindungsarten für Codelisten

Eine Codeliste soll ausschließlich mittels der in Abschnitt 9.4, “Nutzung von Codelisten” beschriebenen Code-Typen 1 bis 4 in einem XÖV-Standard genutzt werden. Code-Datentypen sind stets benannte Datentypen.

Begründung: Durch diese vier Varianten der Einbindung von Codelisten in einen XÖV-Standard, basierend auf dem XÖV-Datentyp Code, ist die Nutzung einer einheitlichen Struktur und Benennung bezüglich der Übermittlung von Codes unter Wahrung der Flexibilität für verschiedene Anwendungskontexte gewährleistet. Benannte Code-Datentypen gewährleisten Nachnutzbarkeit sowie eine dedizierte Behandlung in der XÖV-Produktionsumgebung.

Prüfung: Die Einhaltung dieser Regel wird durch die Verwendung der XÖV-Produktionsumgebung in einer aktuell gültigen Version sichergestellt.

6.2.2. Namen für Bausteine und Eigenschaften

Namensregeln dienen der problemlosen Weiterverarbeitung der XSD-Schemas im Zuge der Implementierung des XÖV-Standards, helfen bei der Erstellung eines einheitlichen Standards und erleichtern die Integration externer Standards bzw. ermöglichen anderen Standards den eigenen Standard reibungsloser wiederzuverwenden.

NDR-11 `SOLL`: Erlaubte Zeichen für Namen

Erläuterung: Namen von globalen Bausteinen und lokalen Eigenschaften eines XÖV-Standards sollen nur die im Folgenden aufgeführten Zeichen enthalten:

a-z und A-Z (Buchstaben in Groß- und Kleinschreibung)
0-9 (Ziffern)
. (Punkt)
_ (Unterstrich)
- (Bindestrich)

Begründung: Vor dem Hintergrund der Implementierbarkeit eines XÖV-Standards mit gängigen Technologien (Programmiersprachen, Bindings) müssen Einschränkungen bei der Nutzung von Namen berücksichtigt werden. Programmiersprachen akzeptieren im Allgemeinen keine Umlaute, Leerzeichen sowie andere Sonderzeichen innerhalb von Bezeichnern. Gängige XML-Binding-Werkzeuge akzeptieren zwar alle erlaubten XML-Namen, passen diese jedoch abhängig von den genutzten Sonderzeichen an, sodass die Sonderzeichen in der Regel nicht bestehen bleiben. Hinweis: Die Verwendung der in dieser Regel zugelassenen Zeichen sollte hinsichtlich ihrer Eignung zur technischen Implementierung des XÖV-Standards durch das jeweilige XÖV-Vorhaben geprüft werden, da auch für diese eine Akzeptanz durch alle Binding-Werkzeuge nicht abschließend gesichert ist.

Prüfung: Die Einhaltung dieser Regel wird durch die Verwendung der XÖV-Produktionsumgebung in einer aktuell gültigen Version sichergestellt.

NDR-13 `SOLL`: Versionsübergreifend eindeutige Nachrichtennamen

Nachrichten sollen im Kontext eines XÖV-Standards versionsübergreifend eindeutige Namen aufweisen. Namen veralteter Nachrichten sollen nicht für neue Nachrichten wiederverwendet werden.

Begründung: Eindeutige Nachrichtennamen sind insbesondere im Kontext von Clearingstellen und Fachanwendungen von großer Bedeutung. Falls eine Nachricht im Rahmen der Fortentwicklung eines XÖV-Standards entfällt, sollte ihr Name zur Vermeidung von Interpretationsproblemen durch Mehrdeutigkeiten bei der Datenübermittlung vermieden werden.

6.2.3. Dokumentation

Die Dokumentation der Bestandteile eines XÖV-Standards ist essenziell für seine Implementierung in Anbetracht des Umfangs und der Komplexität, die XÖV-Standards im Allgemeinen erreichen.

NDR-32 `MUSS`: Dokumentation der Metadaten des Standards

Die Metadaten eines XÖV-Standards und seiner Version müssen im XÖV-Fachmodell dokumentiert werden.

Erläuterung: Die Metadaten eines Standards sind, wie in Abschnitt 5.2.3, “Sprachelement und Anhang C, beschrieben, zu dokumentieren.

Begründung: Mit den Metadaten eines XÖV-Standards und seiner Version werden grundlegende fachliche und technische Informationen zum Standard dokumentiert. Die Angabe der Metadaten im XÖV-Fachmodell erlaubt Mensch (z. B. Nutzern des Standards und der XÖV-Zertifizierungsstelle) wie Maschine (z. B. XGenerator und XRepository) die unmittelbare Einsicht und Verarbeitung der Informationen.

Prüfung: Die Einhaltung dieser Regel wird durch die Verwendung der XÖV-Produktionsumgebung in einer aktuell gültigen Version sichergestellt.

NDR-19 `SOLL`: Dokumentation in deutscher Sprache

Alle Dokumntationsbestandteile eines XÖV-Standards sollen in deutscher Sprache verfasst sein.

Erläuterung: Neben der Dokumentation in deutscher Sprache können zusätzlich weitere Sprachen gewählt werden. Ein Abweichen von dieser Regel, sodass ausschließlich in anderen Sprachen dokumentiert wird, ist in bestimmten Kontexten gegebenenfalls sinnvoll.

Begründung: Ein XÖV-Standard wird durch fachliche Anforderungen der öffentlichen Verwaltung Deutschlands bestimmt. Die Nutzung der deutschen Sprache bei der Dokumentation von XÖV-Standards unterstützt die semantische Interoperabilität zwischen diesen Standards der deutschen Verwaltung. Im Falle von Standards in einem europäischen Kontext oder bei technischen Begriffen kann jedoch die Wahl einer anderen Sprache vorteilhaft sein.

6.2.4. Wiederverwendung

Die Wiederverwendung existierender fachlicher und technischer Inhalte des eigenen Standards, anderer XÖV-Standards sowie der von der XÖV-Koordination herausgegebenen XÖV-Bausteine fördert die Einheitlichkeit innerhalb und zwischen XÖV-Standards und damit deren Interoperabilität.

NDR-33 `MUSS`: Codelisten konform zu den Regelungen des Codelisten-Handbuchs

Alle durch den Standard herausgegebenen Codelisten müssen konform zu den Regelungen des Codelisten-Handbuchs sein (Codelisten-Handbuch). Die in Verbindung mit dem vorliegenden XÖV-Handbuch gültige(n) Version(en) des Codelisten-Handbuchs können der unter Gültige XÖV-Konfigurationen veröffentlichten Tabelle entnommen werden.

Wird ein Standard in einer neuen Version herausgegeben, können bereits bestehende Codelistenversionen in unveränderter Form weiterverwendet werden. Eine Aktualisierung entsprechend der Tabelle der gültigen Konfigurationen muss für eine durch den Standard herausgegebene Codeliste zwingend dann erfolgen, wenn sie in einer neuen Version herausgegeben wird.

Begründung: Für zum Codelisten-Handbuch konforme Codelisten ist ein Mindestmaß an Konsistenz und Vollständigkeit im Bereich ihrer Daten, Metadaten und Strukturen sichergestellt, die eine standardübergreifend einheitliche Modellierung (nur für XÖV classic) und Nutzung im XÖV-Fachmodell ermöglichen. Die Konformität zum Codelisten-Handbuch ist darüber hinaus eine Voraussetzung für die automatisierte Übersetzung der Codelisteninhalte durch die durch die XÖV-Produktionsumgebung in die verschiedenen Bestandteile des Standards sowie die Bereitstellung der im XÖV-Fachmodell modellierten Codelisten im XRepository.

Prüfung: Die Einhaltung dieser Regel wird in classic durch die Nutzung von Codelisten aus dem XRepository sowie die Nutzung der XÖV-Produktionsumgebung in einer aktuell gültigen Version sichergestellt, wenn sie unterhalb des Pakets "Codelisten/eigene Codelisten" im XÖV-Fachmodell vorliegen.

NDR-22 `MUSS`: Konsistenz von Codelisten in XÖV-Fachmodell und XRepository (nur für XÖV classic)

Die im XÖV-Fachmodell eines Standards modellierten Codelisten müssen hinsichtlich ihrer Daten und identifizierenden Metadaten konsistent zur entsprechenden Codeliste im XRepository sein, sofern sie dort bereitgestellt ist. Eine Einschränkung der Menge der Codes einer Codeliste ist möglich.

Begründung: Eine Verletzung dieser Regel hätte zur Folge, dass die Kommunikationspartner unterschiedliche Codelisten verwendeten. Eine Interoperabilität bezüglich des Austauschs und der Interpretation von Codes wäre in diesem Fall nicht mehr gewährleistet.

NDR-24 `SOLL`: Nutzung der XÖV-Basisnachricht

Generische Nachrichteneigenschaften sollen auf Basis der mit der XÖV-Bibliothek bereitgestellten XÖV-Basisnachricht einheitlich für alle Nachrichten eines XÖV-Standards genutzt werden.

Erläuterung: Die XÖV-Basisnachricht legt die Grundstruktur von XÖV-Nachrichten fest. Sie beinhaltet fachunabhängige Angaben zur eindeutigen Identifikation der Nachricht, des Autors und des Lesers (Routinginformationen), sowie zum Standard und dem eingesetzten Fachverfahren. Der standardübergreifende Einsatz der XÖV-Basisnachricht stellt darüber hinaus für IT-Verfahren, die mehrere Standards implementieren, eine weitergehende Erleichterung dar.

Begründung: Durch die Wiederverwendung generischer Nachrichteneigenschaften wird die Implementierung des Standards in IT-Verfahren vereinfacht.

Prüfung: Die Einhaltung dieser Regel wird durch die Verwendung der XÖV-Produktionsumgebung in einer aktuell gültigen Version sichergestellt.

6.2.5. XML Schema-Konformität

Die XSD-Schemas eines XÖV-Standards basieren auf der von dem W3C empfohlenen XML Schema-Definitionssprache.

NDR-28 `MUSS`: Valide W3C XSD-Schemas

Alle XSD-Schemas eines XÖV-Standards müssen gültig bezüglich der XML Schema-Spezifikation des W3C sein (siehe hierzu W3C XML Schema Part 1).

Begründung: Ausschließlich technisch valide XSD-Schemas bilden eine Grundlage für den maschinellen Datenaustausch.

Prüfung: Die Einhaltung dieser Regel wird durch die Verwendung der XÖV-Produktionsumgebung in einer aktuell gültigen Version sichergestellt.

6.2.6. Namensräume und Versionen

Namensräume und Versionen sind für eine eindeutige Zuordnung von XSD-Schemas zu einem XÖV-Standard notwendig.

NDR-29 `MUSS`: Identifizierende Namensräume

Alle im Rahmen eines XÖV-Standards definierten Bausteine müssen sich in einem Namensraum befinden, der den betroffenen XÖV-Standard eindeutig identifiziert.

Erläuterung: Diese Regel bezieht sich auf die Ziel-Namensräume der XSD-Schemas des Standards (Sprachelement namespace im Kontext der Konfiguration des XÖV-Fachmodells oder eines konkreten Schemapakets) sowie die dazugehörigen Präfixe (Sprachelement prefix).

Begründung: Eindeutige Namensräume sind für die Verwendung und Implementierung der XSD-Schema-Inhalte eines XÖV-Standards notwendig.

Prüfung: Die Einhaltung dieser Regel wird durch die Verwendung der XÖV-Produktionsumgebung in einer aktuell gültigen Version sichergestellt.

NDR-30 `MUSS`: Versionierung der XSD-Schemas

Jedes XSD-Schema eines XÖV-Standards muss versioniert sein.

Erläuterung: Diese Regel bezieht sich auf die Versionen der XSD-Schemas des Standards (Sprachelement version im Kontext der Konfiguration des XÖV-Fachmodells oder eines konkreten Schemapakets).

Begründung: Versionen müssen die Entwicklungsstände eines XSD-Schemas und damit den Entwicklungsstand eines XÖV-Standards eindeutig identifizieren. Dieses Vorgehen ist unter anderem für den Versionswechsel im laufenden Betrieb unentbehrlich.

Prüfung: Die Einhaltung dieser Regel wird durch die Verwendung der XÖV-Produktionsumgebung in einer aktuell gültigen Version sichergestellt.

NDR-31 `SOLL`: Namensräume mit Versionen

Die im Kontext eines XÖV-Standards definierten Namensräume sollen die Version des Standards enthalten.

Begründung: Eine neue Version eines XÖV-Standards definiert einen anderen Namensraum als dessen Vorgängerversion. Bei der Verwendung von Inhalten eines XÖV-Standards, das heißt bei der Nutzung von Inhalten eines bestimmten Namensraums, soll feststehen, welcher Version eines Standards die Inhalte zugrunde liegen.

Beispiel: www.xgewerbeanzeige.de/spezifikation/2.1

7. Good Practices

Die unter diesem Abschnitt beschriebenen Good Practices sollen dem Modellierenden eine Unterstützung bei der individuellen Ausgestaltung seines XÖV-Fachmodell bieten. Good Practices können als Hinweise auf spezifische Umsetzungsvarianten verstanden werden. Diese Hinweise liegen, anders als die Namens- und Entwurfsregelungen mit den Verbindlichkeitsstufen SOLL und MUSS, ausschließlich in der Verbindlichkeitsstufe EMPFEHLUNG vor und sind somit nicht zertifizierungsrelevant.

Die Einhaltung der Good Practice Empfehlungen ist nicht relevant für die Einstufung eines Standards als XÖV-Standard. Die Empfehlungen basieren auf den Namens- und Entwurfsregeln der Verbindlichkeitsstufe EMPFEHLUNG früherer Versionen des XÖV-Handbuchs.

7.1. GP im Überblick

Good Practices dokumentieren in der Praxis bewährten Namens- und Entwurfsmuster und können so helfen, den Entwicklungsaufwand zu reduzieren sowie die Einheitlichkeit und damit die Zugänglichkeit eines XÖV-Standards zu verbessern. Alle Good Practices werden mit den mit der XÖV-Produktionsumgebung ausgelieferten Prüfanweisungen automatisiert auf das XÖV-Fachmodell angewendet.

Tabelle 10. Übersicht der Empfehlungen
Nr.	Kurzbeschreibung
Strukturen und Inhalte
GP-5	Detaillierte Struktur eines XÖV-Fachmodells
GP-6	Nutzung von XML-Attributen und XML-Elementen
GP-7	XML-Wildcard-Elemente mit Namensraum
GP-9	Umgang mit speziellen Anforderungen an die Nutzung von Codelisten
GP-34	Modellierung von Codelistenversionen als benannte Typen
Namen für XML-Attribute, -Elemente und -Typen
GP-12	Erlaubte Zeichen für Klassifikationen in Namen
GP-14	Namen in deutscher Sprache
GP-15	Groß- und Kleinschreibung von (und innerhalb zusammengesetzter) Namen
GP-16	Namensstruktur globaler Elemente
GP-17	Versionsübergreifend eindeutige Nachrichtennummern
GP-18	Namen von XML Schema-Dateien
Dokumentation
GP-20	Dokumentation der Rechtsgrundlagen
Wiederverwendung
GP-25	Aufbau und Nutzung wiederverwendbarer Datentypen
GP-26	Physische Speicherorte von XML Schema-Definitionen als URL
GP-27	Verwendung des ursprünglichen Namensraumpräfixes bei XML Schema-Importen

7.2. GP im Detail

Die im Folgenden aufgeführten Empfehlungen sind analog zur Kategorisierung innerhalb der Übersichtstabelle geordnet.

7.2.1. Strukturen und Inhalte

GP-5: Detaillierte Struktur eines XÖV-Fachmodells

Für die inhaltliche Gliederung eines XÖV-Fachmodells wird die Nutzung der im folgenden dargestellten (Paket-)Struktur empfohlen.

Beispiel 4. Root-Element des XÖV-Fachmodells

Notation classic: das XÖV-Fachmodell muss auf der obersten Ebene ein mit xsdXModel stereotypisierte UML-Paket enthalten. Der Name des Pakets muss dem Namen (technisch) des Standards entsprechen (siehe hierzu Anhang C, ), alle im folgenden dargestellten Pakete sind Bestandteil dieses Pakets.
Notation lite: das XÖV-Fachmodell hat das Root-Element xoev-fachmodell, alle im folgenden dargestellten Pakete sind Kindelemente dieses Elements.

Basisdatentypen: XML Schema-Paket, welches technische Datentypen zur Wiederverwendung in Nachrichten und anderen Datentypen enthält, z. B. Einschränkungen von XML Schema-Datentypen, wie String.Max50.
Baukasten: XML Schema-Paket, welches alle fachlichen Datentypen zur Wiederverwendung innerhalb des gesamten XÖV-Standards enthält, z. B. Anschrift.
Nachrichten oder Fachmodule: Ein oder mehrere Pakete, unter denen die Nachrichtenhauptgruppen zusammengefasst sind.
(Mindestens eine) Hauptgruppe: XML Schema-Paket, welches eine Nachrichtenhauptgruppe repräsentiert und damit alle fachlich zusammengehörenden Nachrichten und hauptgruppenspezifische Datentypen, z. B. Nachricht formularverzeichnis.anfrage.formular.010301 in der Hauptgruppe Formularverzeichnis.

Neben den aufgeführten Modellen und Paketen können je nach gewählter XÖV-Notation weitere Inhalte in einem XÖV-Fachmodell abgebildet werden. In der Notation clasic können beispielsweise Prozessmodelle und -beschreibungen Bestandteil des XÖV-Fachmodell sein. Bei Bedarf können weitere Strukturen in Form von Unterpaketen gebildet werden, um die Klassifikationen verwandter Modellbestandteile vorzunehmen.

Begründung: Ziel ist die Etablierung eines einheitlichen Aufbaus für XÖV-Fachmodelle und der XML Schema-Definitionen eines XÖV-Standards, durch den insbesondere der inhaltliche Zugang zu fremden XÖV-Standards erleichtert wird. Weiterhin ermöglicht die Einhaltung dieser Empfehlung die Nutzung der von der XÖV-Koordination bereitgestellten XÖV-Übersetzungsanweisungen für die automatisierte Erstellung einer DocBook-Dokumentation zu einem XÖV-Standard.

Beispiel einer detaillierten Verzeichnisstruktur (XZuFi):

Prüfung: Die Einhaltung dieser Regel wird durch die Verwendung der XÖV-Produktionsumgebung in einer aktuell gültigen Version sichergestellt.

GP-6: Nutzung von XML-Attributen und XML-Elementen

Es wird empfohlen, fachliche Inhalte eines XÖV-Standards mit Hilfe von XML-Elementen zu modellieren, technische bzw. erläuternde Metadaten dagegen mit der Hilfe von XML-Attributen.

Erläuterung: Während fachliche Inhalte im Kontext von Nachrichten und Datentypen mit XML-Elementen umgesetzt werden, können Metadaten, d. h. Informationen über die eigentlichen fachlichen Inhalte, mittels XML-Attributen ausgedrückt werden.

Beispiel eines Metadatums: Erstellungszeitpunkt einer Nachricht

GP-7: XML-Wildcard-Elemente mit Namensraum

Für XML-Wildcard-Elemente wird die Angabe eines Namensraums empfohlen.

Erläuterung: Diese Regel bezieht sich auf spezielle XML-Elemente (xs:any), die beliebige Inhalte umfassen dürfen. Für sie sollte ein Namensraum angegeben sein.

Begründung: Mit der Angabe des Namensraumes besteht die Möglichkeit, die übermittelten Inhalte, deren zugrunde liegende XML Schema-Definitionen im Voraus nicht bekannt sind, einer XML Schema-Validierung zu unterziehen.

Prüfung: Die Einhaltung dieser Regel wird durch die Verwendung der XÖV-Produktionsumgebung in einer aktuell gültigen Version sichergestellt.

GP-9: Umgang mit speziellen Anforderungen an die Nutzung von Codelisten

Die Nutzung der in Abschnitt 9.4, “Nutzung von Codelisten” beschriebenen Modellierungsmuster wird empfohlen, sofern durch diese die speziellen Anforderungen eines XÖV-Vorhabens abgedeckt werden.

Begründung: Eine einheitliche Verwendung dieser Muster erhöht die Interoperabilität und erleichtert die spätere Implementierung.

GP-34: Modellierung von Codelistenversionen als benannte Typen

Es wird empfohlen, Codelistenversionen auf der XML Schema-Ebene wie in Abschnitt 9.4, “Nutzung von Codelisten” beschrieben, zu spezifizieren.

Begründung: Erfahrungen bei der Implementierung von XÖV-Standards in Fachverfahren zeigten, dass im Kontext des Code-Typs 1 die Nutzung von Codelistenversionen als anonyme Typen problematisch ist, weil automatisierte Mechanismen zur Verarbeitung von XML Schema-Definitionen keine Java-Enumerationen erzeugen können.

Prüfung: Die Einhaltung dieser Regel wird durch die Verwendung der XÖV-Produktionsumgebung in einer aktuell gültigen Version sichergestellt.

7.2.2. Namen für XML-Attribute, -Elemente und -Typen

Namensregeln dienen der problemlosen Weiterverarbeitung der XML Schema-Definitionen im Zuge der Implementierung, helfen bei der Erstellung eines einheitlichen Standards und erleichtern die Integration externer Standards bzw. ermöglichen anderen Standards den eigenen Standard reibungsloser wiederzuverwenden.

GP-12: Erlaubte Zeichen für Klassifikationen in Namen

Zur Abbildung von Klassifikationen in Namen wird empfohlen, Punkte zu verwenden.

Erläuterung: Namen von XML-Attributen, XML-Elementen und XML-Typen, die innerhalb einer XML Schema-Definition spezifiziert sind, sollen in ihrem Namen das Zeichen “.” (Punkt) nur zur Abbildung einer Klassifikation verwenden.

Begründung: Die Nutzung eines Punktes in Namen dient einem einheitlichen Klassifikationsmuster von XML Schema-Bestandteilen und erleichtert bei der Betrachtung eines XÖV-Standards die Zuordnung von zusammengehörenden Bestandteilen zu einer Klasse von XML Schema-Bestandteilen.

Beispiele: leistungsverzeichnis.anfrage.leistungskategorie.010102, rueckmeldung.auswertung.0203, String.Latin

Prüfung: Die Einhaltung dieser Regel wird durch die Verwendung der XÖV-Produktionsumgebung in einer aktuell gültigen Version sichergestellt.

GP-14: Namen in deutscher Sprache

Es wird empfohlen, alle Bestandteile eines XÖV-Standards in deutscher Sprache zu benennen.

Erläuterung: Diese Regel bezieht sich auf Bausteine und ihre Eigenschaften.

Begründung: Ein XÖV-Standard wird durch fachliche Anforderungen der öffentlichen Verwaltung Deutschlands bestimmt. Die Namen der verschiedenen inhaltlichen Bestandteile eines Standards spiegeln in der Regel diese Fachlichkeit wider. Im Falle von Standards im europäischen Kontext oder bei technischen Begriffen kann jedoch die Wahl einer anderen Sprache geeignet sein. Ebenso können sich in Standards der deutschen Verwaltung Abweichungen ergeben. Insbesondere bei generischen Datentypen kann dies der Fall sein, wenn diese zum Beispiel von XML Schema-Datentypen abgeleitet werden und die Herleitung im Namen des ableitenden Typs ausgedrückt werden soll.

GP-15: Groß- und Kleinschreibung von (und innerhalb zusammengesetzter) Namen

Es wird empfohlen, in Namen von XML-Typen eines XÖV-Standards alle eigenständigen Wörter mit einem Großbuchstaben zu beginnen (Upper Camel Case).
In den Namen von XML-Attributen und -Elementen wird eine analoge Schreibweise empfohlen. Hier sollte das erste Zeichen des Namens jedoch ein Kleinbuchstabe sein (Lower Camel Case).
Im Falle von Namen globaler XML-Elemente, und damit auch von Nachrichten, wird ebenfalls die Lower Camel Case Schreibweise empfohlen. Nach Klassifikationsmerkmalen in Namen globaler Elemente sollte ebenfalls mit einem Kleinbuchstaben begonnen werden.

Erläuterung: Diese Empfehlung bezieht sich auf XML-Typen, -Attribute und -Elemente.

Beispiele:

zu a): (Typ) Organisation, NameNatuerlichePerson, EntscheidungVonAmtsWegen
zu b): (Element) strasse, namenNachVeraenderung
(Attribut) listURI
zu c): (Nachricht) anmeldung.datenbereitstellung.0301

Prüfung: Die Einhaltung dieser Regel wird durch die Verwendung der XÖV-Produktionsumgebung in einer aktuell gültigen Version sichergestellt.

GP-16: Namensstruktur globaler Elemente

Für Nachrichtennamen wird empfohlen, den Namen der jeweiligen Nachrichtenhauptgruppe als Präfix voranzustellen. Das Präfix wird mit einem Punkt von dem eigentlichen Namen der Nachricht abgegrenzt.

Erläuterung: Diese Regel bezieht sich unter anderem auf Nachrichten.

Begründung: Die Angabe des Präfixes ermöglicht die Zuordnung von globalen Elementen zu einer sie umfassenden Hauptgruppe.

Beispiele:

rueckmeldung.auswertung.0203 (rueckmeldung = Gruppe, auswertung.0203 = Name)
rueckmeldung.unplausibel.0204 (rueckmeldung = Gruppe, unplausibel.0204 = Name)

Prüfung: Die Einhaltung dieser Regel wird durch die Verwendung der XÖV-Produktionsumgebung in einer aktuell gültigen Version sichergestellt.

GP-17: Versionsübergreifend eindeutige Nachrichtennummern

Es wird empfohlen, Nachrichten im Kontext eines XÖV-Standards versionsübergreifend eindeutige Nummern als Namenssuffix zuzuweisen. Das Suffix wird mit einem Punkt abgegrenzt. Darüber hinaus wird empfohlen, ungültig gewordene Nachrichtennummern nicht im Kontext neuer Nachrichten wiederzuverwenden.

Erläuterung: Diese Regel bezieht sich auf Nachrichten.

Begründung: Eindeutige Nachrichtennummern sind insbesondere im Kontext von Clearingstellen und Fachanwendungen von großer Bedeutung.

Beispiel: datenaustausch.quittierung.fehler.0112

Prüfung: Die Einhaltung dieser Regel wird durch die Verwendung der XÖV-Produktionsumgebung in einer aktuell gültigen Version sichergestellt.

GP-18: Namen von XML Schema-Dateien

Es wird empfohlen, die Namen der XML Schema-Dateien eines Standards mit dem Namen (technisch) des Standards beginnen zu lassen.

Erläuterung: Diese Regel bezieht sich auf die Dateinamen der XML Schema-Definitionen und den Namen (technisch) des Standards (siehe hierzu Anhang C, ).

Begründung: Die Zugehörigkeit der XML Schema-Definitionen zu einem bestimmten XÖV-Standard sollte auch auf Dateiebene direkt erkennbar sein.

Beispiel: xzufi-baukasten.xsd

Prüfung: Die Einhaltung dieser Regel wird durch die Verwendung der XÖV-Produktionsumgebung in einer aktuell gültigen Version sichergestellt.

7.2.3. Dokumentation

Die Dokumentation der Bestandteile eines XÖV-Standards ist essentiell für seine Implementierung in Anbetracht des Umfangs und der Komplexität, die XÖV-Standards im Allgemeinen erreichen.

GP-20: Dokumentation der Rechtsgrundlagen

Für die Nachrichten eines XÖV-Standards wird empfohlen, ihre rechtlichen Grundlagen innerhalb des Standards zu dokumentieren.

Erläuterung: Die Rechtsgrundlagen zu einer Nachricht sollen dokumentiert werden.

Begründung: Die Dokumentation der Rechtsgrundlagen dient der Nachvollziehbarkeit der rechtlichen Notwendigkeit für den Datenaustausch.

Prüfung: Die Einhaltung dieser Regel wird durch die Verwendung der XÖV-Produktionsumgebung in einer aktuell gültigen Version sichergestellt.

7.2.4. Wiederverwendung

GP-25: Aufbau und Nutzung wiederverwendbarer Datentypen

Es wird empfohlen, im Baukasten eines XÖV-Standards wiederverwendbare Bausteine aufzubauen und sie in konkreten Nachrichtenkontexten über XML Schema-Restriktionen auf den jeweiligen Anwendungsfall auszurichten.

Erläuterung: Im Baukasten eines XÖV-Standards werden grundlegende, zur Wiederverwendung und damit für den Einsatz in verschiedenen Nachrichtenkontexten vorgesehene Bausteine spezifiziert. Sie stellen somit die Grundlage für die modellierung nachrichtenspezifischer Bausteine dar.

Begründung: Die Einhaltung dieser Empfehlung soll durch eine konsequente Wiederverwendung die Einheitlichkeit und Wartbarkeit eines XÖV-Standards fördern.

GP-26: Physische Speicherorte von XML Schema-Definitionen als URL

Es wird empfohlen, den physischen Speicherort einer XML Schema-Definition in Form eines öffentlichen URLs anzugeben.

Erläuterung: Diese Regel bezieht sich auf das XML Schema-Attribut schemaLocation.

Begründung: Ein öffentlicher Zugang zu den XML Schema-Definitionen eines XÖV-Standards über individuelle URLs ist vorteilhaft, da XML Schema-Validatoren hierdurch auf extern vorliegende XML Schema-Definitionen anderer Namensräume zugreifen können. Die jeweiligen externen Speicherorte werden im Kontext eines XML Schema-Imports bestimmt.

GP-27: Verwendung des ursprünglichen Namensraumpräfixes bei XML Schema-Importen

Es wird empfohlen, die Bestandteile einer importierten XML Schema-Definition über genau den Namensraumpräfix anzusprechen, der in der importierten XML Schema-Definition genutzt wird.

Erläuterung: Bei der Einbindung externer XML Schema-Definitionen in einen XÖV-Standard besteht die Möglichkeit, das originäre Namensraumpräfix der importierten XML Schema-Definition durch ein neues Präfix zu ersetzen.

Begründung: Aus Gründen der Nachvollziehbarkeit ist die unveränderte Verwendung von Präfixen importierter XML Schema-Definitionen sinnvoll.

Beispiel: Für den Namensraum des über die XÖV-Bibliothek bereitgestellten Datentyps Code ist das Präfix xoev-code definiert. Im Falle der Nutzung des Code-Datentyps in einem XÖV-Standard sollte ebendieser Präfix beibehalten werden damit ein Rückschluss auf den Ursprung des Datentyps erleichtert wird.

Prüfung: Die Einhaltung dieser Regel wird durch die Verwendung der XÖV-Produktionsumgebung in einer aktuell gültigen Version sichergestellt.

8. Nutzung der XÖV-Bibliothek

Die von der XÖV-Koordination herausgegebene XÖV-Bibliothek enthält alle XÖV-Bausteine, ausgenommen XÖV-Codelisten, welche mit den weiteren existierenden Codelisten im XRepository bereitgestellt werden.

Ausnahme bilden hier die von den XÖV-Bausteinen selbst genutzten Codelisten. Diese werden zwar mit der XÖV-Bibliothek mitgeliefert, sollen aber nicht über die XÖV-Bibliothek genutzt werden.

In diesem Kapitel wird die Methodik zum Umgang mit der XÖV-Bibliothek und ihren Inhalten im eigenen XÖV-Fachmodell beschrieben. Das Spezifikationsdokument wie auch Informationen zu den Fassungen der Bibliothek sind über XÖV docs unter XÖV-Bibliothek bereitgestellt.

Mit der XÖV-Bibliothek werden den Standardisierungsvorhaben alle durch die XÖV-Koordination herausgegebenen XÖV-Bausteine zur Verfügung gestellt.

Die XÖV-Bibliothek erlaubt eine komfortable und einheitliche Einbindung und Nutzung dieser Bausteine in XÖV-Standards. Veröffentlicht wird die Bibliothek, den XÖV-Prinzipien zur Entwicklung von Standards folgend, in der Form eines Modells in der Notation classic und lite. Damit kann sie als externes Modell direkt in ein XÖV-Fachmodell eingebunden und die enthaltenen Bausteine ohne Weiteres genutzt werden.

8.1. Einbindung und Nutzung

Die XÖV-Bibliothek wird in unterschiedlichen Editionen für die Notationen classic (MagicDraw und Papyrus) und lite bereitgestellt. Sie wird wie in Abschnitt "Sprachelement Externes Modell" beschrieben und in NDR-2 geregelt, als externes Modell in das XÖV-Fachmodell eingebunden. Hierdurch können alle enthaltenen XÖV-Bausteine wie in Kapitel 9, beschrieben, im eigenen Standard nachgenutzt werden.

8.2. Versionen und Versionsumstiege

Alle Bausteine der XÖV-Bibliothek werden separat betrieben und versioniert. Mit neuen Fassungen der XÖV-Bibliothek werden in der Regel auch neue Versionen einzelner Bausteine bereitgestellt. Ältere Versionen dieser Bausteine bleiben jedoch erhalten, sodass XÖV-Standards individuell auf die neuen Versionen eines Bausteins umsteigen können.

Zu jedem Zeitpunkt kann die aktuelle Fassung der XÖV-Bibliothek genutzt werden, da bei einer Aktualisierung der Bibliothek bereits existierende Bausteinversionen weiterhin mit bereitgestellt werden.

Dies bedeutet im Umkehrschluss, dass die Einbindung einer aktuelleren Version der XÖV-Bibliothek nicht automatisch zu einem Versionsumstieg der Bausteine führt. Ein solcher Umstieg muss explizit durch den Betreiber des Standards vorgenommen werden.

Der konkrete Umstieg auf eine neue Fassung der XÖV-Bibliothek erfolgt auf Dateiebene, indem die frühere Modell-Datei der XÖV-Bibliothek durch die neue Datei ersetzt wird.

In classic Notation stehen damit direkt beim Öffnen des XÖV-Fachmodells alle neuen Versionen der XÖV-Bausteine zur Verfügung.

In der lite Notation ist zusätzlich die neu eingesetzte Fassung der XÖV-Bibliothek im XÖV-Fachmodell anzugeben (Notationselement fassung in externesModell).

Tabelle 11. Beispiel zur Umstellung des XÖV-Fachmodells (`lite` Notation) auf eine neue Fassung der XÖV-Bibliothek
vorher	`<externesModell kennung="urn:xoev-de:kosit:xoev:bibliothek:xoevbibliothek" version="2022-12-15"/>`
nachher	`<externesModell kennung="urn:xoev-de:kosit:xoev:bibliothek:xoevbibliothek" version="2025-11-14"/>`

8.3. Teilen der XÖV-Bibliothek mit weiteren externen Modellen

XÖV-Standards binden häufig neben der XÖV-Bibliothek weitere externe XÖV-Modelle ein, welche in der Regel ebenso Bausteine aus der XÖV-Bibliothek nutzen. Die XÖV-Bibliothek ermöglicht auch in diesen Situationen eine problemlose Konfiguration der Nutzung der XÖV-Bausteine.

Sofern der XÖV-Standard, welcher externe, XÖV-konforme Standards einbindet, die aktuelle Fassung der XÖV-Bibliothek nutzt, liegen ihm und allen externen Modellen alle existierenden Versionen der XÖV-Bausteine vor. Jedes involvierte Modell hat somit Zugriff auf die jeweils benötigte Version eines Bausteins, ohne dass mehrere verschiedene Fassungen der Bibliothek eingebunden werden müssen.

Die folgende Abbildung veranschaulicht einen Vorgang aus der Praxis. Das XInneres-Fachmodul XPersonenstand nutzt das XInneres-Basismodul (im Folgenden kurz "XInneres") mit vereinheitlichten Bausteinen für Standards der Innenverwaltung. Sowohl XPersonenstand, als auch XInneres nutzen den XÖV-Datentyp Code. Sollte zukünftig eine neue Version dieses Datentyps vorliegen, könnte der Fall eintreten, dass XPersonenstand auf diese Version umsteigt, jedoch noch kein aktualisiertes XInneres-Release existiert, sodass die eingebundene XInneres-Version weiterhin den früheren Stand des Code-Datentyps nutzt. XPersonenstand bindet auch in diesem Fall ausschließlich die aktuelle Fassung der XÖV-Bibliothek ein, die alle Versionen des Code-Datentyps enthält.

Abbildung 8. Versionsumstieg am Beispiel XInneres Fachmodul XPersonenstand

9. Bausteine und ihre Nutzung

Zur Spezifikation der zur Datenübermittlung genutzten Strukturen und Formate können in einem XÖV-Standard unterschiedliche Ansätze gewählt werden.

lokale (anonyme) Strukturen: diese werden nur an einer bestimmten Stelle im Standard verwendet und sind nicht wiederverwendbar.
Bausteine: diese sind wiederverwendbar und können an mehreren Stellen eingesetzt werden.

In der Praxis werden durch einen XÖV-Standard immer beide Ansätze in unterschiedlichen Anteilen genutzt.

Bausteine können aus dem eigenen Standard, aus anderen Standards oder als XÖV-Bausteine vorliegen. Im Folgenden werden die verschiedenen Arten von Bausteinen erläutert.

Datentypen Datentypen dienen der Spezifikation von Datenformaten (einfache Datentypen) und Datenstrukturen (komplexe Datentypen). Neben den individuell modellierten Datentypen (z. B. "AllgemeinerName") existieren speziell modellierte Code-Datentypen für die Nutzung von Codelisten (z. B. "Code.Antwortstatus"). Zu den Datentypen zählen ebenfalls die als W3C-Datentypen bezeichneten XML Schema-Grunddatentypen (z. B. "string", "date" und "boolean") sowie die XÖV-Datentypen.

XÖV-Datentypen

XÖV-Datentypen sind grundlegende, von der XÖV-Koordination bereitgestellte Bausteine. Sie liegen als XML-Datentypen in veröffentlichten XSD-Schemas vor und stehen in der XÖV-Bibliothek zur direkten Nutzung zur Verfügung.

Zu den XÖV-Datentypen zählen sowohl eigene Typen der XÖV-Koordination (z. B. „Code“, XÖV-Basisnachricht) als auch externe Datentypen aus anderen Standards und Normen, wie DIN-konforme Unicode-Zeichentypen, Geodatenbausteine der GML (OGC) und XML-Namespace-Inhalte (W3C).

XÖV-Datentypen aus den Regelungsbereichen anderer Organisationen, wie beispielsweise die Datentypen zur DIN 91379 Norm, werden von der XÖV-Koordination zur Unterstützung einer direkten, technischen Nutzung in einem von der XÖV-Koordination betriebenen XSD-Schema bereitgestellt.

Alle XÖV-Datentypen sind im Spezifikationsdokument der XÖV-Bibliothek dokumentiert.

Globale Eigenschaft Die auf Basis eines XÖV-Standards im XML-Format übermittelten Daten werden mittels Eigenschaften, das heißt XML-Attributen und XML-Elementen, strukturiert und mit spezifischer Bedeutung übermittelt (z. B. im Element "nachname"). Die Struktur und das Format der in einer Eigenschaft übermittelten Daten werden wiederum über den (Daten)Typ der Eigenschaft bestimmt. Wenn der Verbund aus Eigenschaft und Datentyp (z. B. Element "nachname" des Typs "AllgemeinerName") an verschiedenen Stellen eines Standards gleichartig eingesetzt, d. h. referenziert, werden soll, wird die Eigenschaft als globale Eigenschaft modelliert.

Globale Eigenschaftengruppe Eigenschaften können explizit zu einer benannten globalen Eigenschaftengruppe zusammengefasst und als solche einheitlich nachgenutzt werden. Werden diese in XML-Schema als Elementgruppen abgebildet, so können diese als Sequenz, Auswahl oder All-Gruppe repräsentiert werden.

Codeliste Eine Codeliste beschreibt in einer definierten Version eine abgeschlossene Menge von Werten (Codes) mit einer eindeutig definierten Bedeutung in einem konkreten inhaltlichen Kontext (z. B. Codes "DE", "DJ, "DK", usw. aus der Liste der Country Codes). Durch die Nutzung einer Codeliste in einem Code-Datentyp wird eine Liste von Codes als Wertemenge realisiert.

Nachricht Die auf Basis eines XÖV-Standards durchgeführte Kommunikation ist Prozess- und Nachrichtenorientiert. Die Kommunikationspartner übermitteln auf der Basis rechtlicher Regelungen Nachrichten mit genau den Daten, die zum Fortführen bzw. zum Abschluss des Datenübermittlungsprozesses erforderlich sind. Eine Nachricht beschreibt somit die Gesamtheit der zu einem bestimmten Zweck zu übermittelnden Daten. Ihre Gesamtstruktur ergibt sich aus einem bestimmten Aufbau aus Bausteinen der zuvor beschriebenen Arten. Nachrichten stellen globale Elemente mit spezieller Bedeutung dar.

In den folgenden Abschnitten werden die Wege zur Nutzung der verschiedenen Bausteinarten erläutert.

Als spezielle Art globaler Elemente wird die Bausteinart Nachricht im Folgenden nicht gesondert betrachtet.

9.1. Nutzung von Datentypen

Die Wege zur Nutzung eines Datentyps sind grundsätzlich unabhängig vom konkreten Charakter des Datentyps, das heißt unabhängig davon, ob es sich um

einfache Datentypen oder komplexe Datentypen,
(gewöhnliche) Datentypen, Code-Datentypen oder W3C-Datentypen,
eigene Datentypen, Datentypen anderer Standards oder XÖV-Datentypen,
Datentypen aus Datenmodell-Syntaxen bzw.
alleinstehende Datentypen oder abgeleitete Datentypen

handelt.

Die Nutzung eines Datentyps kann in zwei grundlegende Wege eingeteilt werden. Bei der direkten Nutzung wird ein Datentyp als Typ einer Eigenschaft eingesetzt. Bei der Nutzung per Ableitung wird ein Datentyp als Basistyp eines abgeleiteten Datentyps eingesetzt. Der abgeleitete Datentyp kann den Basistyp erweitern oder einschränken.

9.1.1. Direkte Nutzung

Lokale und globale Eigenschaften können einen Datentyp direkt nutzen. Das folgende Beispiel zeigt einen DatentypA, dessen eigenschaft1 einen DatentypB nutzt. Letzterer kann grundsätzlich, wie zuvor beschrieben, eines beliebigen Charakters sein.

Einschränkungen: In Eigenschaften, die Attribute repräsentieren, können nur einfache Datentypen eingesetzt werden.

Tabelle 12. Direkte Nutzung eines Datentyps in lokalen Eigenschaften
`classic`	`lite`
	`<datentyp name="DatentypA"> <eigenschaft name="eigenschaft1" typ="p:DatentypB"/> </datentyp>`

In classic erhält eine UML-Eigenschaft, hier modelliert als UML-Attribut einer UML-Klasse, die Klasse DatentypB als Typ.

Die Nutzung eines Datentyps kann in UML-Klassendiagrammen auch als Beziehung zwischen der (indirekt) nutzenden Klasse und der Klasse des genutzten Datentyps dargestellt werden. Dabei wird eine gerichtete Komposition (UML-Assoziation mit schwarzem Diamanten auf der nutzenden Seite und Pfeil auf der genutzten) eingesetzt.

Die Modellierungsvarianten (Klassenattribut oder Beziehung) unterscheiden sich nur in ihrer Darstellung. Inhaltlich sind sie äquivalent, führen also zum selben Ergebnis in den Bestandteilen des Standards.

In der Praxis wird die Darstellung als Klassenattribut häufig für Eigenschaften einfachen Datentyps gewählt. Zur leichteren Erfassung umfangreicherer Strukturen und Zusammenhänge wird die Nutzung komplexer Datentypen in der Regel mittels Beziehungen veranschaulicht.

In lite erhält die Eigenschaft den Typ durch Angabe seines Namens DatentypB mit vorangesetztem, per Doppelpunkt separiertem Präfix (im Beispiel p). Das Präfix dient dabei der eindeutigen Bestimmung des genutzten Datentyps und entspricht in der Regel dem Namensraumpräfix des XSD-Schemas, in dem der Datentyp spezifiziert ist.

In unterschiedlichen Kontexten können Datentypen mit dem gleichen Namen auftreten. XML sieht hierfür den Einsatz von Namensräumen vor. Beispielsweise liegt der datatypeC in der XÖV-Bibliothek mehrfach vor. Über das jeweilige (Namensraum)Präfix wird die Angabe des konkret genutzten Datentyps eindeutig: dinspec91379:datatypeC ist von din91379:datatypeC unterscheidbar.

Bei der in den vorherigen Beispielen herangezogenen eigenschaft1 handelt es sich um eine lokale Eigenschaft. Globale Eigenschaften können Datentypen ebenso direkt nutzen.

Tabelle 13. Direkte Nutzung eines Datentyps in globalen Eigenschaften
`classic`	`lite`
	`<globaleEigenschaft name="eigenschaft2" typ="p:DatentypB"/>`

In classic wird die globale eigenschaft2 mittels einer UML-Abhängigkeitsbeziehung mit dem genutzten DatentypB verbunden.

In lite wird die Nutzung analog dem Vorgehen bei lokalen Eigenschaften bestimmt.

9.1.2. Nutzung per Ableitung

Ein Datentyp kann als Basistyp eines anderen Datentyps genutzt werden. Bei dieser Ableitung kann entweder eine Erweiterung (Extension) oder eine Einschränkung (Restriction) des genutzten Basistyps erfolgen.

Das folgende Beispiel zeigt einen DatentypC und eine globale eigenschaft3, die jeweils den DatentypB als Basistyp um die eigenschaft4 erweitern.

Einschränkungen: Einfache Datentypen können nur um Attribute erweitert werden.

classic

lite

<datentyp name="DatentypC" basistyp="p:DatentypB">
  <eigenschaft name="eigenschaft4" typ="xs:string"/>
</datentyp>
<globaleEigenschaft name="eigenschaft3" basistyp="p:DatentypB">
  <eigenschaft name="eigenschaft4" typ="xs:string"/>
</globaleEigenschaft>

In classic wird die Erweiterung mittels einer UML-Generalisierungsbeziehung modelliert.

In lite erfolgt die Angabe des Basistyps im gleichnamigen Attribut. Wie bei der direkten Nutzung wird der Name der Eindeutigkeit halber von einem Präfix begleitet.

Einschränkungen werden analog den Erweiterungen modelliert mit der zusätzlichen Angabe, dass es sich bei der Ableitung um eine Restriction handelt. Das folgende Beispiel zeigt eine Einschränkung des W3C-Datentyps string, d. h. eines einfachen Datentyps, durch den DatentypD auf Zeichenfolgen mit maximal fünf Zeichen. Die in XML Schema für XML-Restrictions einfacher Datentypen vorgesehen Facetten (z. B. maxLength oder pattern) stehen in der Modellierungssprache zur Verfügung.

Tabelle 15. Einschränkung eines einfachen Datentyps
`classic`	`lite`
	`<datentyp name="DatentypD" basistyp="xs:string" restriction="true" maxLength="5"/>`

In classic wird die Tatsache, dass es sich um eine Einschränkung handelt, mittels des Stereotyps xsdRestriction ausgezeichnet. Der Stereotyp stellt mit seinen Eigenschaften die Restriction-Facetten bereit.

In lite wird eine Restriction mit dem gleichnamigen Attribut und dem Wert true modelliert. Die Restriction-Facetten stehen ebenso als Attribute bereit.

Neben Datentypen können auf die gleiche Weise auch globale Eigenschaften einen Basisdatentyp einschränkend ableiten.

Das folgende Beispiel zeigt die Nutzung von DatentypE als komplexen Basistyp im eingeschränkten DatentypF. Wie bei der Ableitung einfacher Datentypen sind auch an dieser Stelle Ableitungsmöglichkeiten wie in XML Schema gegeben. Beispielsweise dürfen Multiplizitäten strenger werden (im Beispiel wird eigenschaft5 mandatorisch und eigenschaft6 verboten) und Eigenschaften eingeschränkte Typen erhalten (im Beispiel erhält eigenschaft5 den W3C-Datentyp token, der selbst eine Einschränkung des W3C-Datentyps string darstellt).

classic

lite

<datentyp name="DatentypE">
  <eigenschaft name="eigenschaft5"
    multiplizitaet="0..1" typ="xs:string"/>
  <eigenschaft name="eigenschaft6"
    multiplizitaet="0..1" typ="xs:string"/>
</datentyp>
<datentyp name="DatentypF"
  basistyp="p:DatentypE" restriction="true">
  <eigenschaft name="eigenschaft5" typ="xs:token"/>
</datentyp>

In classic und lite erfolgt die Kennzeichnung von Einschränkungen bei komplexen Datentypen wie bei Einschränkungen einfacher Datentypen.

In einschränkenden komplexen Datentypen sind analog den Regelungen in XML Schema alle Eigenschaften des Basistyps aufzuführen, die der eingeschränkte Datentyp selbst besitzen soll. Sofern der Basistyp direkt oder indirekt eine Erweiterung eines Basisytps darstellt, sind auch die geerbten Eigenschaften zu berücksichtigen.

9.1.3. Spezielle Nutzungsszenarien

Einfache Datentypen können genutzt werden, um die durch sie spezifizierten Wertemengen zu vereinigen. Im folgenden Beispiel vereinigt DatentypG die Menge der möglichen Tagesdaten (spezifiziert im W3C-Datentyp date) mit der Menge der möglichen Zeitpunkte (spezifiziert im W3C-Datentyp dateTime).

Tabelle 17. Datentypen als Union Members
`classic`	`lite`
	`<datentyp name="DatentypG"> <union> <memberType>xs:date</memberType> <memberType>xs:dateTime</memberType> </union> </datentyp>`

In classic wird ein vereinigender Datentyp mit dem Stereotyp xsdUnion gekennzeichnet. Die zur Vereinigung genutzten Datentypen werden über Abhängigkeitsbeziehungen verbunden. Letztere werden jeweils mit dem Stereotyp xsdUnionMember annotiert.

In lite wird die Vereinigung innerhalb eines Datentyps über das Element union gebildet. Die Namen der genutzten Datentypen werden zusammen mit zugehörigem Präfix in den Kindelementen memberType angegeben.

9.2. Nutzung von globalen Eigenschaften

HINWEIS AN DIE EDITOREN: Die Beschreibung von Beispielen zur Nutzung globaler Eigenschaften soll im vollen Umfang (inkl. Beispiele) erst nach Finalisierung der XÖV-Bibliothek erstellt in einem XÖV-Handbuch 4.0.1 bereitgestellt werden.

Globale Eigenschaften können an allen Stellen eingesetzt, d. h. referenziert werden, an denen alternativ lokale Eigenschaften spezifiziert werden können. Wie bei Datentypen gilt, dass die Wege zur Nutzung globaler Eigenschaften grundsätzlich unabhängig sind von ihrem konkreten Charakter, das heißt unabhängig davon, ob es sich um

Eigenschaften mit einfachen oder komplexen Datentypen,
globale Elemente oder globale Attribute,
(gewöhnliche) globale Elemente oder Nachrichten,
eigene globale Eigenschaften, globale Eigenschaften anderer Standards oder aus der XÖV-Bibliothek,
globale Eigenschaften aus Datenmodell-Syntaxen bzw.
alleinstehende globale Eigenschaften oder abgeleitete

handelt.

Das folgende Beispiel zeigt die Nutzung der globalen eigenschaft7 als Eigenschaft von DatentypH.

Tabelle 18. Nutzung einer globalen Eigenschaft
`classic`	`lite`
	`<datentyp name="DatentypH"> <eigenschaft referenz="p:eigenschaft7"/> </datentyp>`

In classic erfolgt die Nutzung einer globalen Eigenschaft als Beziehung zwischen der nutzenden Klasse und der Klasse der globalen Eigenschaft. Dabei wird eine gerichtete Komposition (UML-Assoziation mit schwarzem Diamanten auf der nutzenden Seite und Pfeil auf der genutzten Seite) eingesetzt.

Wenn anstelle der Darstellung einer Beziehung eine Darstellung mittels Klassenattribut gewählt wird, erhält dieses keinen eigenen Namen und die genutzte Eigenschaft (im Beispiel eigenschaft7) als UML-Typ.

In lite wird an der Stelle, an der die globale Eigenschaft eingesetzt werden soll, ein Element eigenschaft mit einer entsprechenden Referenz erstellt. Die Referenz enthält den Namen der Eigenschaft ergänzt um das zugehörige Präfix.

9.3. Nutzung von globalen Eigenschaftengruppen

HINWEIS AN DIE EDITOREN: Die Beschreibung von Beispielen zur Nutzung globaler Eigenschaftengruppen soll im vollen Umfang (inkl. Beispiele) erst nach Finalisierung der XÖV-Bibiothek erstellt in einem XÖV-Handbuch 4.0.1 bereitgestellt werden.

Globale Eigenschaftengruppen können an allen Stellen eingesetzt, d. h. referenziert werden, an denen alternativ Eigenschaften spezifiziert werden können. Wie bei globalen Eigenschaften sind die Wege zur Nutzung globaler Eigenschaftengruppen grundsätzlich unabhängig von ihrem konkreten Charakter sind, das heißt unabhängig davon, ob es sich um

Element- oder Attributgruppen,
Elementgruppen als Sequenz, Choice oder All-Gruppe,
eigene globale Eigenschaftengruppen, globale Eigenschaftengruppen anderer Standards oder aus der XÖV-Bibliothek bzw.
globale Eigenschaftengruppen aus Datenmodell-Syntaxen

handelt.

Das folgende Beispiel zeigt die Nutzung der globalen gruppe1 in DatentypI.

Tabelle 19. Nutzung einer globalen Eigenschaftengruppe
`classic`	`lite`
	`<datentyp name="DatentypI"> <eigenschaftengruppe referenz="p:gruppe1"/> </datentyp>`

In classic erfolgt die Nutzung einer globalen Eigenschaft analog der Nutzung globaler Eigenschaften als Beziehung zwischen der nutzenden Klasse und der Klasse der globalen Eigenschaftengruppe. Dabei wird eine gerichtete Komposition (UML-Assoziation mit schwarzem Diamanten auf der nutzenden Seite und Pfeil auf der genutzten Seite) eingesetzt.

Wenn anstelle der Darstellung einer Beziehung eine Darstellung mittels Klassenattribut gewählt wird, erhält dieses keinen eigenen Namen und die genutzte Eigenschaftengruppe (im Beispiel gruppe1) als UML-Typ.

In lite wird an der Stelle, an der die globale Eigenschaftengruppe eingesetzt werden soll, ein Element eigenschaftengruppe mit einer entsprechenden Referenz erstellt. Die Referenz enthält den Namen der Gruppe ergänzt um das zugehörige Präfix.

9.4. Nutzung von Codelisten

Dieser Abschnitt beschreibt die Wege zur Nutzung von zum Codelisten-Handbuch konformen Codelisten, inklusive XÖV-Codelisten, mittels Code-Datentypen im XÖV-Fachmodell und den damit verbundenen, einheitlichen Einsatz des XÖV-Bausteins Code.

Eine detaillierte Anleitung zur Entwicklung von Codelisten unter Anwendung der XÖV-Modellierungsprache in den vorgesehenen Notationen wird in dem von der KoSIT herausgegebenen Codelisten-Handbuch gegeben.

9.4.1. XÖV-Baustein `Code`

Die XÖV-Koordination stellt mit dem Datentyp Code einen XÖV-Baustein bereit, der eine einheitliche Übermittlung von Codes aus Codelisten ermöglicht. Er sieht die folgenden Strukturen zur Übermittlung vor:

code: In diesem XML-Element wird der Code einer Codeliste übermittelt.
name: Mit diesem optionalen XML-Element kann die Beschreibung des Codes, wie in der genutzten Beschreibungsspalte der Codeliste vorgegeben, übermittelt werden.
listURI: Mit diesem XML-Attribut wird die Kennung der Codeliste übermittelt, in deren Kontext der jeweilige Code zu interpretieren ist.
listVersionID: Die konkrete Version der zur Übermittlung des Codes genutzten Codeliste wird mit diesem XML-Attribut übermittelt.

Der XÖV-Baustein Code findet, wie in den folgenden Abschnitten erläutert, bei der Modellierung eines konkreten Code-Datentyps implizit Anwendung.

9.4.2. Modellierung eines Code-Datentyps

Die XÖV-Modellierungssprache ermöglicht eine auf die Nutzung einer Codeliste fokussierte Modellierung eines Code-Datentyps mit dem gleichnamigen Sprachelement Code-Datentyp. Im Kontext eines Code-Datentyps kann die zu nutzende Codeliste bzw. Codelistenversion über eine Angabe der Kennung der Codeliste und der Version der Codeliste erfolgen. Darüber hinaus stehen weitere Sprachmittel für die Konfiguration zur Verfügung. Ihre konkrete Verwendung wird in den folgenden Abschnitten im Kontext der verschiedenen Nutzungsszenarien erläutert.

Tabelle 20. Modellierung eines Code-Datentyps in den XÖV-Notationen
`classic`	Klasse ohne Eigenschaften mit Stereotyp `xsdNamedType` (und ggf. Stereotyp `xoevCodeTyp4`) und Nutzungsbeziehung zu einer Codeliste oder Codelistenversion, d. h. zu einer Klasse mit dem Stereotyp `xoevCodeliste` oder `xoevVersionCodeliste`; Nutzungsbeziehung ggf. mit Stereotyp `xoevCodeTyp1`, `xoevCodeTyp2` oder `xoevCodeTyp3`
`lite`	Element `codeDatentyp`

Mit der Modellierung eines konkreten Code-Datentyps (z. B. "Code.Antwortstatus") im XÖV-Fachmodell findet eine implizite Nutzung und Ausprägung des XÖV-Bausteins Code statt. Bei der Überführung des XÖV-Fachmodells in XSD-Schemas wird dies über eine XML-Einschränkung zwischen dem konkreten Code-Datentyp und dem als Basistyp eingesetzten XÖV-Bausteins Code realisiert.

Die Modellierung eines Code-Datentyps fokussiert auf die Konfiguration der Nutzung einer Codeliste und führt bei der Erstellung der Bestandteile eines XÖV-Standards automatisiert zu einer Nutzung des XÖV-Bausteins Code. Damit unterscheidet sich die Modellierung eines Code-Datentyps grundsätzlich von der Modellierung anderer Datentypen, deren Strukturen, Formate und Ableitungen explizit modelliert werden.

9.4.3. Szenarien der Codelistennutzung

In XÖV-Standards können Codelisten grundsätzlich auf vier verschiedene Arten mit unterschiedlichen Auswirkungen auf die Flexibilität und Vorgaben bei der Übermittlung von Codes genutzt werden. In dieser Hinsicht wird von vier Typen der Codelistennutzung gesprochen. Der Nutzungstyp wird anhand der spezifischen Anforderungen und Bedingungen der jeweiligen Datenübermittlungsszenarien ausgewählt.^[5] Die vier Typen der Codelistennutzung sind im Codelisten-Handbuch im Abschnitt 2.2 Einbindung von Codelisten im Detail beschrieben.

Nutzungstyp 4 (Unbenannte Codeliste)

Für die Anwendung des Nutzungstyps 4 wird ein Code-Datentyp ohne Angabe der Kennung der Codeliste und der Version der Codeliste modelliert.

Der Nutzungstyp 4 wird in den XÖV-Notationen wie folgt umgesetzt:

Beispiel 5. Nutzungstyp 4

classic

lite

<codeDatentyp name="Code.Country-Codes.Beispiel_Typ4"/>

In der Notation classic wird die Klasse des Code-Datentyps mit den Stereotypen xsdNamedType und xoevCodeTyp4 annotiert. Eine Beziehung zu einer konkreten Codelistenversion oder Codeliste wird im Regelfall nicht hergestellt.

In der Notation lite wird das Element codeDatentyp ohne die Angabe einer @kennung und @version modelliert.

Die Modellierung führt zu folgender Abbildung in XML Schema:

Beispiel 6. XSD-Schema-Beispiel (Nutzungstyp 4)

   <xs:complexType name="Code.Country-Codes.Beispiel_Typ4">
      <xs:complexContent>
         <xs:restriction base="xoev-code:Code">
            <xs:sequence>
               <xs:element name="code" type="xs:token" form="unqualified"/>
            </xs:sequence>
            <xs:attribute name="listURI" type="xs:anyURI" use="required"/>
            <xs:attribute name="listVersionID" type="xs:normalizedString" use="required"/>
         </xs:restriction>
      </xs:complexContent>
   </xs:complexType>

Nutzungstyp 3

Für die Anwendung des Nutzungstyps 3 wird ein Code-Datentyp mit Angabe der Kennung der Codeliste modelliert.

Der Nutzungstyp 3 wird in den XÖV-Notationen wie folgt umgesetzt:

Beispiel 7. Nutzungstyp 3

classic

lite

<codeDatentyp name="Code.Country-Codes.Beispiel_Typ3" kennung="urn:xoev-de:kosit:codeliste:country-codes"/>

In der Notation classic wird im Falle des Nutzungstyps 3 die Klasse des Code-Datentyps über eine UML-Nutzungsbeziehung mit der UML-Klasse der Codeliste verbunden.

Die Nutzungsbeziehung muss nur dann mit dem Stereotyp xoevCodeTyp3 annotiert werden, wenn eine weitergehende Konfiguration vorgenommen werden soll.

In der Notation lite wird für die Verwendung des Nutzungstyps 3 das Element codeDatentyp unter Angabe der @kennung und ohne Angabe der @version verwendet.

Die Modellierung führt zu folgender Abbildung im Schema:

Beispiel 8. Schema-Beispiel (Nutzungstyp 3)

 <xs:complexType name="Code.Country-Codes.Typ3">
      <xs:annotation>
         <xs:appinfo>
            <codeliste>
               <nameLang>Country Codes</nameLang>
               <nameKurz>Country Codes</nameKurz>
               <nameTechnisch>Country-Codes</nameTechnisch>
               <kennung>urn:xoev-de:kosit:codeliste:country-codes</kennung>
               <beschreibung>Die Codeliste basiert auf der Staats- und Gebietssystematik... [für die beispielhafte Darstellung gekürzt]</beschreibung>
               <herausgebernameLang>Koordinierungsstelle für IT-Standards</herausgebernameLang>
               <herausgebernameKurz>KoSIT</herausgebernameKurz>
            </codeliste>
         </xs:appinfo>
      </xs:annotation>
      <xs:complexContent>
         <xs:restriction base="xoev-code:Code">
            <xs:sequence>
               <xs:element name="code" type="xs:token" form="unqualified"/>
            </xs:sequence>
            <xs:attribute name="listURI"
                          type="xs:anyURI"
                          use="optional"
                          fixed="urn:xoev-de:kosit:codeliste:country-codes"/>
            <xs:attribute name="listVersionID" type="xs:normalizedString" use="required"/>
         </xs:restriction>
      </xs:complexContent>
   </xs:complexType>

Nutzungstyp 2

Für die Anwendung des Nutzungstyps 2 wird ein Code-Datentyp unter Angabe der Kennung der Codeliste und der Version der Codeliste modelliert. Außerdem wird über das Sprachelement Codes Schemavalidiert bestimmt, dass die aus der Codeliste übermittelten Codes nicht schemavalidiert werden sollen (Wert false).

Der Nutzungstyp 2 wird in den XÖV-Notationen wie folgt umgesetzt:

Beispiel 9. Nutzungstyp 2

classic

lite

<codeDatentyp name="Code.Country-Codes.Beispiel_Typ2" kennung="urn:xoev-de:kosit:codeliste:country-codes" version="1.0"/>

Im Falle des Nutzungstyps 2 wird in der Notation classic die Klasse des Code-Datentyps über eine UML-Nutzungsbeziehung mit der UML-Klasse der Codelistenversion verbunden. Die Beziehung wird mit dem Stereotyp xoevCodeTyp2 annotiert.

Um in der Notation lite den Nutzungstyp 2 zu verwenden, wird die zu nutzende Codelistenversion über die Attribute @kennung und @version des Elements codeDatentyp bestimmt. Außerdem wird das Kindelement codesSchemavalidiert mit dem Wert false angegeben.

Die Modellierung führt zu folgender Abbildung im Schema:

Beispiel 10. Schema-Beispiel (Nutzungstyp 2)

Hier klicken um Beispiel einzublenden

  <xs:complexType name="Code.Country-Codes.Typ2">
      <xs:annotation>
         <xs:appinfo>
            <codeliste>
               <nameLang>Country Codes</nameLang>
               <nameKurz>Country Codes</nameKurz>
               <nameTechnisch>Country-Codes</nameTechnisch>
               <kennung>urn:xoev-de:kosit:codeliste:country-codes</kennung>
               <beschreibung>Die Codeliste basiert auf der Staats- und Gebietssystematik... [für die beispielhafte Darstellung gekürzt]</beschreibung>
               <herausgebernameLang>Koordinierungsstelle für IT-Standards</herausgebernameLang>
               <herausgebernameKurz>KoSIT</herausgebernameKurz>
            </codeliste>
            <versionCodeliste>
               <version>8</version>
               <beschreibung>Die Version 8 wurde auf Antrag aus der XÖV-Community angepasst. Details können hier eingesehen werden: https://projekte.kosit.org/xoev/betrieb-public/-/issues/48</beschreibung>
               <bezugsort>https://www.destatis.de/DE/Methoden/Klassifikationen/Staat-Gebietsystematik/staatsangehoerigkeit-gebietsschluessel.html</bezugsort>
               <bezugsort>https://www.iso.org/obp/ui/#search</bezugsort>
               <datumGueltigkeitAb>2022-05-11</datumGueltigkeitAb>
               <versionCodelistenHandbuch>1.2</versionCodelistenHandbuch>
               <aenderungZurVorversion>"PS"... [für die beispielhafte Darstellung gekürzt]</aenderungZurVorversion>
            </versionCodeliste>
            <codelistenspalten>
               <ISOAlpha2code>
                  <spaltennameLang>ISO Alpha-2 code</spaltennameLang>
                  <datentyp>string</datentyp>
                  <codeSpalte>true</codeSpalte>
                  <verwendung>required</verwendung>
                  <empfohleneCodeSpalte>true</empfohleneCodeSpalte>
               </ISOAlpha2code>
               <DESTATIS-Code-Staat>
                  <spaltennameLang>DESTATIS Code Staat</spaltennameLang>
                  <datentyp>string</datentyp>
                  <codeSpalte>false</codeSpalte>
                  <verwendung>optional</verwendung>
                  <empfohleneCodeSpalte>false</empfohleneCodeSpalte>
               </DESTATIS-Code-Staat>
               <ShortName>
                  <spaltennameLang>Short Name</spaltennameLang>
                  <datentyp>string</datentyp>
                  <codeSpalte>false</codeSpalte>
                  <verwendung>optional</verwendung>
                  <empfohleneCodeSpalte>false</empfohleneCodeSpalte>
               </ShortName>
               <FullName>
                  <spaltennameLang>Full Name</spaltennameLang>
                  <datentyp>string</datentyp>
                  <codeSpalte>false</codeSpalte>
                  <verwendung>optional</verwendung>
                  <empfohleneCodeSpalte>false</empfohleneCodeSpalte>
               </FullName>
               <ISONumeric>
                  <spaltennameLang>ISO Numeric</spaltennameLang>
                  <datentyp>string</datentyp>
                  <codeSpalte>false</codeSpalte>
                  <verwendung>optional</verwendung>
                  <empfohleneCodeSpalte>false</empfohleneCodeSpalte>
               </ISONumeric>
               <Status>
                  <spaltennameLang>Status</spaltennameLang>
                  <datentyp>string</datentyp>
                  <codeSpalte>false</codeSpalte>
                  <verwendung>optional</verwendung>
                  <empfohleneCodeSpalte>false</empfohleneCodeSpalte>
               </Status>
            </codelistenspalten>
            <genutzteCodeSpalte>ISOAlpha2code</genutzteCodeSpalte>
         </xs:appinfo>
      </xs:annotation>
      <xs:complexContent>
         <xs:restriction base="xoev-code:Code">
            <xs:sequence>
               <xs:element name="code" type="xs:token" form="unqualified"/>
            </xs:sequence>
            <xs:attribute name="listURI"
                          type="xs:anyURI"
                          use="optional"
                          fixed="urn:xoev-de:kosit:codeliste:country-codes"/>
            <xs:attribute name="listVersionID"
                          type="xs:normalizedString"
                          use="optional"
                          fixed="8"/>
         </xs:restriction>
      </xs:complexContent>
   </xs:complexType>

Nutzungstyp 1

Für die Anwendung des Nutzungstyps 1 wird ein Code-Datentyp unter Angabe der Kennung der Codeliste und der Version der Codeliste modelliert. Außerdem wird über das Sprachelement Codes Schemavalidiert bestimmt, dass die aus der Codeliste übermittelten Codes schemavalidiert werden sollen (Wert true; entspricht der Standardeinstellung).

Der Nutzungstyp 1 wird in den XÖV-Notationen wie folgt umgesetzt:

Beispiel 11. Nutzungstyp 1

classic

lite

<codeDatentyp name="Code.Country-Codes.Beispiel_Typ4" kennung="urn:xoev-de:kosit:codeliste:country-codes" version="1.0">
         <codesSchemavalidiert>true</codesSchemavalidiert>
</codeDatentyp>

Im Falle des Nutzungstyps 1 wird in der Notation classic die Klasse des Code-Datentyps über eine UML-Nutzungsbeziehung mit der UML-Klasse der Codelistenversion verbunden. Die Beziehung wird mit dem Stereotyp xoevCodeTyp1 annotiert.

Um in der Notation lite den Nutzungstyp 1 zu modellieren, wird die verwendete Codeliste über die Attribute @kennung und @version des Elements codeDatentyp spezifiziert.

Eine Angabe des Kindelements codesSchemavalidiert ist nur dann erforderlich, wenn die Konfiguration auf der Ebene des XÖV-Fachmodells keine Schemavalidierung für Codes vorsieht. Siehe hierzu auch Anhang A, .

Die Modellierung führt zu folgender Abbildung im Schema:

Beispiel 12. Schema-Beispiel (Nutzungstyp 1)

Hier klicken um Beispiel einzublenden

   <xs:complexType name="Code.Country-Codes.Typ1">
      <xs:annotation>
         <xs:appinfo>
            <codeliste>
               <nameLang>Country Codes</nameLang>
               <nameKurz>Country Codes</nameKurz>
               <nameTechnisch>Country-Codes</nameTechnisch>
               <kennung>urn:xoev-de:kosit:codeliste:country-codes</kennung>
               <beschreibung>Die Codeliste basiert auf der Staats- und Gebietssystematik... [für die beispielhafte Darstellung gekürzt]</beschreibung>
               <herausgebernameLang>Koordinierungsstelle für IT-Standards</herausgebernameLang>
               <herausgebernameKurz>KoSIT</herausgebernameKurz>
            </codeliste>
            <versionCodeliste>
               <version>8</version>
               <beschreibung>Die Version 8 wurde auf Antrag aus der XÖV-Community angepasst. Details können hier eingesehen werden: https://projekte.kosit.org/xoev/betrieb-public/-/issues/48</beschreibung>
               <bezugsort>https://www.destatis.de/DE/Methoden/Klassifikationen/Staat-Gebietsystematik/staatsangehoerigkeit-gebietsschluessel.html</bezugsort>
               <bezugsort>https://www.iso.org/obp/ui/#search</bezugsort>
               <datumGueltigkeitAb>2022-05-11</datumGueltigkeitAb>
               <versionCodelistenHandbuch>1.2</versionCodelistenHandbuch>
               <aenderungZurVorversion>"PS"... [für die beispielhafte Darstellung gekürzt]</aenderungZurVorversion>
            </versionCodeliste>
            <codelistenspalten>
               <ISOAlpha2code>
                  <spaltennameLang>ISO Alpha-2 code</spaltennameLang>
                  <datentyp>string</datentyp>
                  <codeSpalte>true</codeSpalte>
                  <verwendung>required</verwendung>
                  <empfohleneCodeSpalte>true</empfohleneCodeSpalte>
               </ISOAlpha2code>
               <DESTATIS-Code-Staat>
                  <spaltennameLang>DESTATIS Code Staat</spaltennameLang>
                  <datentyp>string</datentyp>
                  <codeSpalte>false</codeSpalte>
                  <verwendung>optional</verwendung>
                  <empfohleneCodeSpalte>false</empfohleneCodeSpalte>
               </DESTATIS-Code-Staat>
               <ShortName>
                  <spaltennameLang>Short Name</spaltennameLang>
                  <datentyp>string</datentyp>
                  <codeSpalte>false</codeSpalte>
                  <verwendung>optional</verwendung>
                  <empfohleneCodeSpalte>false</empfohleneCodeSpalte>
               </ShortName>
               <FullName>
                  <spaltennameLang>Full Name</spaltennameLang>
                  <datentyp>string</datentyp>
                  <codeSpalte>false</codeSpalte>
                  <verwendung>optional</verwendung>
                  <empfohleneCodeSpalte>false</empfohleneCodeSpalte>
               </FullName>
               <ISONumeric>
                  <spaltennameLang>ISO Numeric</spaltennameLang>
                  <datentyp>string</datentyp>
                  <codeSpalte>false</codeSpalte>
                  <verwendung>optional</verwendung>
                  <empfohleneCodeSpalte>false</empfohleneCodeSpalte>
               </ISONumeric>
               <Status>
                  <spaltennameLang>Status</spaltennameLang>
                  <datentyp>string</datentyp>
                  <codeSpalte>false</codeSpalte>
                  <verwendung>optional</verwendung>
                  <empfohleneCodeSpalte>false</empfohleneCodeSpalte>
               </Status>
            </codelistenspalten>
            <genutzteCodeSpalte>ISOAlpha2code</genutzteCodeSpalte>
         </xs:appinfo>
      </xs:annotation>
      <xs:complexContent>
         <xs:restriction base="xoev-code:Code">
            <xs:sequence>
               <xs:element name="code" type="starterpaket:Country-Codes" form="unqualified"/>
            </xs:sequence>
            <xs:attribute name="listURI"
                          type="xs:anyURI"
                          use="optional"
                          fixed="urn:xoev-de:kosit:codeliste:country-codes"/>
            <xs:attribute name="listVersionID"
                          type="xs:normalizedString"
                          use="optional"
                          fixed="8"/>
         </xs:restriction>
      </xs:complexContent>
   </xs:complexType>

Außerdem werden die Einträge der Codeliste in das Schema abgebildet:

Beispiel 13. Schema-Beispiel (Nutzungstyp 1, Fortsetzung)

Hier klicken um Beispiel einzublenden

<xs:simpleType name="Country-Codes">
      <xs:annotation>
         <xs:appinfo>
            <codeliste>
               <nameLang>Country Codes</nameLang>
               <nameKurz>Country Codes</nameKurz>
               <nameTechnisch>Country-Codes</nameTechnisch>
               <kennung>urn:xoev-de:kosit:codeliste:country-codes</kennung>
               <beschreibung>Die Codeliste basiert auf der Staats- und Gebietssystematik... [für die beispielhafte Darstellung gekürzt]</beschreibung>
               <herausgebernameLang>Koordinierungsstelle für IT-Standards</herausgebernameLang>
               <herausgebernameKurz>KoSIT</herausgebernameKurz>
            </codeliste>
            <versionCodeliste>
               <version>8</version>
               <beschreibung>Die Version 8 wurde auf Antrag aus der XÖV-Community angepasst. Details können hier eingesehen werden: https://projekte.kosit.org/xoev/betrieb-public/-/issues/48</beschreibung>
               <bezugsort>https://www.destatis.de/DE/Methoden/Klassifikationen/Staat-Gebietsystematik/staatsangehoerigkeit-gebietsschluessel.html</bezugsort>
               <bezugsort>https://www.iso.org/obp/ui/#search</bezugsort>
               <datumGueltigkeitAb>2022-05-11</datumGueltigkeitAb>
               <versionCodelistenHandbuch>1.2</versionCodelistenHandbuch>
               <aenderungZurVorversion>"PS"... [für die beispielhafte Darstellung gekürzt]</aenderungZurVorversion>
            </versionCodeliste>
            <codelistenspalten>
               <ISOAlpha2code>
                  <spaltennameLang>ISO Alpha-2 code</spaltennameLang>
                  <datentyp>string</datentyp>
                  <codeSpalte>true</codeSpalte>
                  <verwendung>required</verwendung>
                  <empfohleneCodeSpalte>true</empfohleneCodeSpalte>
               </ISOAlpha2code>
               <DESTATIS-Code-Staat>
                  <spaltennameLang>DESTATIS Code Staat</spaltennameLang>
                  <datentyp>string</datentyp>
                  <codeSpalte>false</codeSpalte>
                  <verwendung>optional</verwendung>
                  <empfohleneCodeSpalte>false</empfohleneCodeSpalte>
               </DESTATIS-Code-Staat>
               <ShortName>
                  <spaltennameLang>Short Name</spaltennameLang>
                  <datentyp>string</datentyp>
                  <codeSpalte>false</codeSpalte>
                  <verwendung>optional</verwendung>
                  <empfohleneCodeSpalte>false</empfohleneCodeSpalte>
               </ShortName>
               <FullName>
                  <spaltennameLang>Full Name</spaltennameLang>
                  <datentyp>string</datentyp>
                  <codeSpalte>false</codeSpalte>
                  <verwendung>optional</verwendung>
                  <empfohleneCodeSpalte>false</empfohleneCodeSpalte>
               </FullName>
               <ISONumeric>
                  <spaltennameLang>ISO Numeric</spaltennameLang>
                  <datentyp>string</datentyp>
                  <codeSpalte>false</codeSpalte>
                  <verwendung>optional</verwendung>
                  <empfohleneCodeSpalte>false</empfohleneCodeSpalte>
               </ISONumeric>
               <Status>
                  <spaltennameLang>Status</spaltennameLang>
                  <datentyp>string</datentyp>
                  <codeSpalte>false</codeSpalte>
                  <verwendung>optional</verwendung>
                  <empfohleneCodeSpalte>false</empfohleneCodeSpalte>
               </Status>
            </codelistenspalten>
         </xs:appinfo>
      </xs:annotation>
      <xs:restriction base="xs:token">
         <xs:enumeration value="AD">
            <xs:annotation>
               <xs:appinfo>
                  <DESTATIS-Code-Staat>123</DESTATIS-Code-Staat>
                  <ShortName>Andorra</ShortName>
                  <FullName>das Fürstentum Andorra</FullName>
                  <ISONumeric>020</ISONumeric>
               </xs:appinfo>
            </xs:annotation>
         </xs:enumeration>
         <xs:enumeration value="AE">
            <xs:annotation>
               <xs:appinfo>
                  <DESTATIS-Code-Staat>469</DESTATIS-Code-Staat>
                  <ShortName>Vereinigte Arabische Emirate</ShortName>
                  <FullName>die Vereinigten Arabischen Emirate (Abu Dhabi, Adschman, Dubai, Fudschaira, Ras al Chaima, Schardscha, Umm al Kaiwain)</FullName>
                  <ISONumeric>784</ISONumeric>
               </xs:appinfo>
            </xs:annotation>
         </xs:enumeration>
         <xs:enumeration value="AF">
            <xs:annotation>
               <xs:appinfo>
                  <DESTATIS-Code-Staat>423</DESTATIS-Code-Staat>
                  <ShortName>Afghanistan</ShortName>
                  <FullName>die Islamische Republik Afghanistan</FullName>
                  <ISONumeric>004</ISONumeric>
               </xs:appinfo>
            </xs:annotation>
         </xs:enumeration>
         <xs:enumeration value="AG">
            <xs:annotation>
               <xs:appinfo>
                  <DESTATIS-Code-Staat>320</DESTATIS-Code-Staat>
                  <ShortName>Antigua und Barbuda</ShortName>
                  <FullName>Antigua und Barbuda</FullName>
                  <ISONumeric>028</ISONumeric>
               </xs:appinfo>
            </xs:annotation>

            ...

         <xs:enumeration value="ZW">
            <xs:annotation>
               <xs:appinfo>
                  <DESTATIS-Code-Staat>233</DESTATIS-Code-Staat>
                  <ShortName>Simbabwe</ShortName>
                  <FullName>die Republik Simbabwe</FullName>
                  <ISONumeric>716</ISONumeric>
               </xs:appinfo>
            </xs:annotation>
         </xs:enumeration>
      </xs:restriction>
   </xs:simpleType>

9.4.4. Codelisten im XÖV-Fachmodell

In XÖV-Fachmodellen der Notation lite wird ausschließlich die Nutzung von Codelisten modelliert. Die Codelisten selbst werden in der Genericode-Notation gemäß Codelisten-Handbuch in einem separaten Verzeichnis codelists gehalten. Die Erstellung und Fortschreibung von Codelisten kann mit dem Codelisten-Editor erfolgen. Weitere Informationen können Sie dem Codelisten-Handbuch entnehmen.

XÖV-Fachmodelle der Notation classic enthalten die durch den Standard genutzten Codelisten bzw. Codelistenversionen. Dort lassen sie sich in "eigene Codelisten" und "externe Codelisten" mit der folgenden Definition unterscheiden.

Eigene Codelisten werden im XÖV-Fachmodell des Standards gepflegt und fortgeschrieben. Die eigenen Codelisten und Codelistenversionen eines XÖV-Standards müssen konform zu den Regelungen des Codelisten-Handbuchs sein. Alle eigenen Codelistenversionen werden in der Produktionsphase des Standards durch die XÖV-Produkte geprüft und in das Genericode-Format überführt.

Externe Codelisten sind alle weiteren durch den Standard genutzten Codelisten. Das können beispielsweise Codelisten sein, die durch den Standard herausgegeben, jedoch nicht im XÖV-Fachmodell des Standards gepflegt werden, oder Codelisten fremder Herausgeber. Externe Codelisten und -versionen sollen – soweit möglich – konform zu den Regelungen des Codelisten-Handbuchs sein und werden automatisch in das XÖV-Fachmodell importiert. Codelistenversionen dieser Kategorie werden in der Produktionsphase des Standards durch die XÖV-Produkte weder geprüft noch in das Genericode-Format überführt.

Alle genannten eigenen und externen Codelisten müssen, wie in der folgenden Abbildung beispielhaft dargestellt, im XÖV-Fachmodell auf oberster Ebene unterhalb eines UML-Pakets „Codelisten“ abgelegt werden.

In Einzelfällen kann es erforderlich sein, dass auch bei externen Codelisten und -versionen Anpassungen oder Ergänzungen durch den Standard vorgenommen werden müssen. Damit bei einer erneuten Einbindung dieser Codelisten in das XÖV-Fachmodell die Änderungen nicht überschrieben werden, wird, wie in der Abbildung dargestellt, für die Praxis empfohlen, ein designiertes Paket unter "externe Codelisten" zu erstellen, das alle importierten Codelisten in unveränderter Form enthält.

9.4.5. Modellierung spezieller Anforderungen

Der Abschnitt zur Modellierung spezieller Anforderungen wird für die Verwendung mit XÖV lite überarbeitet und ist Teil der kommenden Version des Handbuchs.

10. Etablierte Datenmodelle und ihre Nutzung

In diesem Kapitel wird das XÖV-Angebot zu den auf Etablierten Datenmodellen basierenden Datenmodell-Syntaxen (kurz DM-Syntaxen) konkretisiert und die Methodik zur Nutzung im eigenen Standard thematisiert.

10.1. XÖV-Angebot zu DM-Syntaxen in der XÖV-Bibliothek

DM-Syntaxen werden in der XÖV-Bibliothek bereitgestellt. Zum Angebot gehören die Originalbausteine der mit den Etablierten Datenmodellen assoziierten XÖV-Standards sowie zur leichteren Nachnutzung aufbereitete Originalbausteine.

Die Bereitstellung der Inhalte zu etablierten Datenmodellen wird mit den Releases der XÖV-Bibliothek ab Q1 2026 beginnen.

10.1.1. Originalbausteine der DM-Syntaxen

Die Originalbausteine einer DM-Syntax werden durch die mit den aktuell unterstützten Etablierten Datenmodellen assoziierten XÖV-Standards XBasisdaten, xdomea und XUnternehmen.Basismodul definiert. Die im Kontext der Datenmodelle relevanten XSD-Schemas dieser Standards werden über die XÖV-Bibliothek bereitgestellt, damit die Originalbausteine der DM-Syntax direkt genutzt werden können. In die XÖV-Bibliothek werden somit in der Regel nur Teile des Gesamtstandards übernommen.

10.1.2. Aufbereitete Bausteine

Bei einzelnen Originalbausteinen der DM-Syntax kann der Fall eintreten, dass sie nicht problemlos nachgenutzt werden können, zum Beispiel aufgrund anonymer Datenstrukturen oder spezieller XML Schema-Sprachmittel. Aus diesem Grund werden in der XÖV-Bibliothek, zusätzlich zu den Originalbausteinen, bei Bedarf einzeln aufbereitete Bausteine zur leichten Wiederverwendung angeboten.

Darüber hinaus kann der Bedarf einer umfassenderen Aufbereitung des Originalangebots zur Unterstützung einer zusätzlichen Modellierungsvariante bestehen. Dieser Bedarf tritt auf, wenn in den mit den Etablierten Datenmodellen assoziierten XÖV-Standards eine Art der Modellierung, und damit die generelle Modellierungsform der Originalbausteine, verfolgt wird, die zu den Modellierungsansätzen bestimmter Nutzungskontexte inkompatibel ist. Siehe hierzu auch den folgenden Abschnitt.

Alle aufbereiteten Bausteine liegen in XÖV-spezifischen XSD-Schemas vor. Sie richten sich hinsichtlich ihrer Ausgestaltung so weit wie möglich nach dem jeweiligen Originalbaustein und nehmen insbesondere keine Veränderung von Inhalten oder Vorgaben gegenüber diesem vor.

In vielen Fällen erlauben die aufbereiteten Bausteine eine Datenübermittlung in den gleichen syntaktischen Strukturen wie der Originalbaustein, zum Beispiel wenn anonyme Strukturen lediglich in benannte überführt wurden oder globale Elemente anstelle lokaler eingesetzt werden. In manchen Fällen ist die Übermittlung in anderen Strukturen erforderlich, zum Beispiel wenn eine Überführung einer nicht ohne Einschränkung nachnutzbaren XML-Union in ein XML-Choice erfolgte.

Aufbereitete Bausteine werden analog und synchron zu den Originalbausteinen betrieben, versioniert und über die XÖV-Bibliothek bereitgestellt.

10.1.3. Bereitstellung von Modellierungsvarianten

Die Ausgestaltung des XÖV-Fachmodells eines XÖV-Standards, der mit einem Etablierten Datenmodell assoziiert ist, und damit die Ausgangsbasis der entsprechenden DM-Syntax, folgt in der Regel einer der beiden folgenden Modellierungsvarianten:

Modellierung globaler Attribute und globaler Elemente mit dahinterliegenden benannten Datentypen; Aufbau von Datentypen unter Nutzung der globalen Attribute und Elemente
Modellierung von benannten (und anonymen) Datentypen mit lokalen Attributen und Elementen; Nutzung der Datentypen als Typen der lokalen Attribute und Elemente

Wenn seitens der XÖV-Koordination festgestellt wird, dass aus methodischer Sicht ein begründeter Anpassungsbedarf am Originalbausteinen vorliegt, wird eine aufbereiteten Variante des Bausteins in der XÖV-Bibliothek angeboten.

Inhalte zur Modellierungsvariante A werden in der XÖV-Bibliothek unter dem Titel "Nutzung per Komposition" angeboten. Damit wird dem nutzenden Standard eine individuelle Zusammenstellung eigener Bausteine aus Bausteinen und -Teilbausteinen der DM-Syntax ermöglicht.

Inhalte zur Modellierungsvariante B werden unter dem Titel "Nutzung per Ableitung" angeboten. Damit wird dem nutzenden Standard neben der direkten Nutzung von Bausteinen der DM-Syntax insbesondere auch eine Nachnutzung mittels Einschränkung (XML-Restriction) und Erweiterung (XML-Extension) ermöglicht.

10.1.4. Auszeichnung des Bezugs zu Datenmodellen

Die Bausteine der DM-Syntaxen und deren Eigenschaften enthalten Informationen zur eindeutigen Zuordnung zu den Inhalten des zugrundeliegenden Datenmodells. Nutzende XÖV-Standards müssen keine weiteren Auszeichnungen vornehmen.

10.2. Nutzung von DM-Syntaxen

Die Bausteine einer DM-Syntax liegen in Form globaler Eigenschaften und/oder globaler Datentypen in der XÖV-Bibliothek vor. Als solche können diese, wie in Kapitel 9, dargestellt, verwendet werden.

Teil III: Glossar und Anhänge

Glossar

Bausteine: Bausteine sind Datenstrukturen, Datenformate und Codelisten eines Standards, die mehrfach verwendet werden können. Die XÖV-Modellierungssprache bietet die Sprachelemente Nachricht, allgemeiner Datentyp und Code-Datentyp sowie Globale Eigenschaft und Globale Eigenschaftengruppe zur Spezifikation von Bausteinen in einem XÖV-Fachmodell an. Ergänzend zu den mit der XÖV-Modellierungssprache angebotenen Sprachelementen kann ein (XÖV-)Standard zudem das Konzept Codeliste zur Spezifikation eines Bausteins nutzen.
Bestandteile eines XÖV-Standards: Die Bestandteile eines XÖV-Standards sind definiert als die durch das Standardisierungsvorhaben erzeugten und bereitgestellten Ergebnisse zum Standard. Ein XÖV-Standard kann aus beliebig vielen Bestandteilen bestehen. Bestimmte Arten von Bestandteilen, wie beispielsweise die XSD-Schemas und das Spezifikationsdokument eines XÖV-Standards sind jedoch obligatorisch.

Die zentralen Bestandteile eines Standards werden automatisiert aus dem XÖV-Fachmodell generiert. Ergänzende, insbesondere dokumentatorische Bestandteile werden darüber hinaus manuell erstellt.

Das XÖV-Fachmodell selbst ist nach dieser Definition nicht Bestandteil des Standards.
Codeliste: Eine Codeliste ist eine Liste von Codes und der Beschreibung ihrer jeweiligen Bedeutung. Die Bedeutung von Codes kann dabei beispielsweise in Form von Namen (Augsburg, Bremen, München, etc.), Begrifflichkeiten (ledig, verheiratet, geschieden, etc.) oder Statusbeschreibungen (Antrag übermittelt, Antrag empfangen, Antrag unvollständig, etc.) vorliegen. In der Datenübermittlung werden Codelisten eingesetzt, um die für einen bestimmten Übermittlungskontext relevanten Sachverhalte eindeutig zu bezeichnen und in der erforderlichen Form zu beschreiben. Im XÖV-Kontext werden Codelisten verwendet, welche konform zum Codelisten-Handbuch ausgestaltet sind.
Codelisten-Editor: Der Codelisten-Editor steht als Web-Anwendung im XRepository zur Verfügung und ermöglicht das Erstellen, Bearbeiten und Validieren von Codelisten.

Weitere Informationen hierzu finden Sie auf www.xrepository.de/cms/hilfe.html#funktionenCLEditor.

Codelisten-Fachmodell: Ein Codelisten-Fachmodell und seine Inhalte sind gemäß der XÖV-Modellierungssprache und den zugehörigen XÖV-Notationen spezifiziert und konform zu den Regelungen des Codelisten-Handbuchs. Notationen zur Erstellung und Pflege eines Codelisten-Fachmodells sind die XÖV-Notation classic und die des OASIS-Standards Genericode.
Codelisten-Handbuch: Mit dem Codelisten-Handbuch wird allen an der Herausgabe und Nutzung von Codelisten Beteiligten eine gemeinsame Basis für eine transparente, qualitätsgesicherte und letztendlich effiziente Ausgestaltung ihrer Aufgaben und Prozesse geboten. Diese gemeinsame Basis wird gebildet durch den im Codelisten-Handbuchs dokumentierten "Standard zur Herausgabe und Nutzung von Codelisten". Die mit dem Standard gegebenen Konformitätskriterien bilden die messbare Grundlage für die Feststellung der Konformität einer Codeliste zu den Vorgaben des Codelisten-Handbuchs.

Weitere Informationen hierzu finden Sie auf docs.xoev.de/codelistenhandbuch/übersicht
Datenmodell-Syntax: Eine Datenmodell-Syntax (kurz DM-Syntax) ist eine XÖV-konforme technische Ausprägung der Bausteine eines Etablierten Datenmodells. Die Bausteine einer DM-Syntax werden als XÖV-Bausteine in der XÖV-Bibliothek zur Verwendung im eigenen XÖV-Fachmodell bereitgestellt.
Dokumentationsbestandteile eines XÖV-Standards: Zu den obligatorischen Dokumentationsbestandteilen eines XÖV-Standards gehören das Spezifikationsdokument (zu jeder Version des Standards) und ein Pflegekonzept (versionsunabhängig). Weitere Dokumentationsbestandteile zum Standard und/oder seiner Versionen sind möglich.
Entwurfsphase: Die Entwurfsphase stellt die erste Phase des XÖV-Entwicklungsprozesses dar, in der die Erfassung und Abbildung aller initial relevanten Informationen zum Standard und zu den geplanten Datenübermittlungsszenarien für Neu- und Bestandsvorhaben erfolgt. Auf die Entwurfsphase folgt die Spezifikationsphase.
Etabliertes Datenmodell: Ein Etabliertes Datenmodell wird im XÖV-Kontext verstanden als technologieunabhängiger, fachübergreifender Datenstandard, der grundlegende Datenbausteine zur Spezifikation eigener Daten und Datenstrukturen definiert. Etablierte Datenmodelle werden nicht als Produkte des XÖV-Rahmenwerks betrieben, sondern unterliegen einem separaten fachlichen Betrieb mit verantwortlichen Herausgebern und individuellen rechtlichen Verbindlichkeiten.

Inhalte zu Etablierten Datenmodellen werden in der Form von Datenmodell-Syntaxen in der XÖV-Bibliothek zur Nutzung bereitgestellt.
Fachmodell: Das Fachmodell eines Standards ist die Summe der in der Entwurfsphase erhobenen Informationen zu den Datenübermittlungsszenarien und den Metadaten des Standards und seiner Version.
Herausgeber: Der Herausgeber einer Codeliste oder eines Standards ist eine Person oder eine Organisation. Sie ist verantwortlich für die fachlichen Inhalte, deren technische Ausgestaltung und der Fortschreibung des Standards.
Inhalt: Die Ergebnisse, welche ein XÖV-Vorhaben einerseits produziert und bereitstellt andererseits selbst nutzt, stellen Inhalte unterschiedlicher Art dar. Zentrale Inhaltsarten sind Standard und Codeliste. Diese können mit den Mitteln des XÖV-Standardisierungsrahmens und seiner Produkte erstellt und verarbeitet werden. Im XÖV-Umfeld besitzt jeder Inhalt eine eindeutige Kennung und wird durch einen festgelegten Satz von Metadaten beschrieben. Beide sind versionsübergreifend gültig, im Kontrast zu den Angaben in der konkreten Version eines Inhalts.

Inhalte sowie zugehörige Dokumente, die eine versionsübergreifende Bedeutung haben (z. B. ein Pflegekonzept), werden im XRepository bereitgestellt.

Weitere Informationen zur Bereitstellung von Inhalten sind im Abschnitt 2.4.1, “XRepository” gegeben.
Kennung: Für die eindeutige und bereichsübergreifende Identifikation von Codelisten und Standards sowie deren Versionen werden im XÖV-Kontext Kennungen auf der Basis der allgemeinen URN-Syntax genutzt. Eine detaillierte Darstellung der Regelungen zur Bildung von Kennungen ist unter Anhang B, gegeben.
Metadaten: Die systematische Nutzung von den im XÖV-Kontext betrachteten Standards und Codelisten erfordert deren Beschreibung in Form von sogenannten Metadaten. Metadaten sind in diesem Zusammenhang beispielsweise der Name, die Beschreibung oder die Kennung eines XÖV-Standards. Die Verwendung von Metadaten ist für XÖV-Standards und deren Versionen im XÖV-Handbuch und für Codelisten und deren Versionen im Codelisten-Handbuch geregelt.
Modellierung: Modellierung ist das Entwickeln und Fortschreiben von konsistenten Informationen zu einem Standard und seinen Datenübermittlungsszenarien in einer oder mehreren Modellierungssprachen und -notationen.
Modellierungswerkzeug: Ein Modellierungswerkzeug ermöglicht die praktische Erstellung und Fortschreibung eines Fachmodells bzw. XÖV-Fachmodells. Die Wahl des Modellierungswerkzeugs ist abhängig von der eingesetzten Notation der XÖV-Modellierungssprache. Für die Notation classic werden derzeit die Modellierungswerkzeuge "MagicDraw" und "Eclipse Papyrus" unterstützt. Für die Notation lite werden mit der XÖV suite ein webbasiertes Werkzeug und mit XML-Editoren wie "Oxygen XML Editor" lokale Modellierungswerkzeuge durch den XÖV-Standardisierungsrahmen unterstützt.

Detaillierte Informationen zu den aktuell unterstützten Versionen und Editionen dieser Modellierungswerkzeuge finden Sie in der über die XÖV-Dokumentationsplattform bereitgestellten FAQ zu diesem Thema.
Pflegekonzept: Ein Betriebskonzept bzw. Pflegekonzept definiert Ziele, Aufgaben, Verantwortungen und Rollen für den Betrieb eines XÖV-Standards und seiner Bestandteile. Es schafft so Transparenz und Klarheit bzgl. der Entwicklung und Pflege des Standards für alle Beteiligten und Betroffenen.

Das Plegekonzept eines Standards benennt neben den zur Durchführung des Betriebs notwendigen Aufgaben und hierzu benötigten Rollen und Verantwortlichkeiten ebenso die für den Betrieb zuständige Stelle sowie grundlegende Aussagen zur Finanzierung.
Produktionsphase: Die Produktionsphase stellt die letzte Phase des XÖV-Entwicklungsprozesses dar, in der die Prüfung und Übersetzung des XÖV-Fachmodells in die Bestandteile des XÖV-Standards erfolgt.
Semantik: Die Semantik definiert – in Abgrenzung zur Syntax – die Bedeutung von Zeichen, Wörtern und Sätzen einer Sprache und in diesem Zusammenhang schließlich die Bedeutung von Bausteinen, Eigenschaften und Werten eines Datenmodells. Die Bedeutung eines konkreten XÖV-Fachmodells hinsichtlich der sich daraus ergebenden Bestandteile des Standards ergibt sich auf Basis der eindeutigen XÖV-Modellierungssprache. Die Bedeutung der in einem XÖV-Fachmodell spezifizierten fachlichen Inhalte ergibt sich wiederum auf der Basis der gewählten Namen und vergebenen Dokumentation der Bausteine und ihrer Eigenschaften.
Spezifikationsdokument: Das Spezifikationsdokument ist ein obligatorischer Dokumentationsbestandteil jeder Version eines XÖV-Standards, in dem alle Informationen enthalten sind, die für das Verständnis und die Umsetzung des Standards erforderlich sind. Hierfür werden neben den Metadaten des Standards und seiner Version insbesondere dessen Datenübermittlungsszenarien sowie die zugehörigen fachlichen und technischen Inhalte eindeutig und im Detail beschrieben.
Spezifikationsphase: Die Spezifikationsphase stellt die zweite Phase des XÖV-Entwicklungsprozesses dar, in der die Konkretisierung von Anforderungen, die Modellierung von Informationen im XÖV-Fachmodell und die Dokumentation von Inhalten erfolgt. Auf die Spezifikationsphase folgt die Produktionsphase.
Sprachelemente der XÖV-Modellierungssprache: Die XÖV-Modellierungssprache definiert mit ihren Sprachelementen eine Reihe von fachlichen Konzepten, hinsichtlich ihrer Semantik, ihrer Eigenschaften und zugehöriger Regelungen. Sprachelemente werden zur Spezifikation von Informationen in einem XÖV-Fachmodell verwendet. Beispiele für Sprachelemente der XÖV-Modellierungssprache sind Metadaten, Nachricht, XSD-Schema und Datentyp.
Syntax: Die Syntax definiert den gültigen Einsatz und Aufbau der Bestandteile einer Sprache, z. B. zu Wörtern und Sätzen, und in diesem Zusammenhang den möglichen Aufbau und inhaltlichen Ausbau eines XÖV-Fachmodells sowie schließlich den möglichen Auf- und Ausbau von Nachrichten zur Datenübermitlung. Die Bedeutung syntaktisch gültiger Konstrukte für Mensch und/oder Maschine ergibt sich wiederum aus ihrer über die eingesetzte Sprache definierte Semantik.
technische Bestandteile des Spezifikationsdokuments: In der Produktionsphase wird ein wesentlicher Anteil der technischen Bestandteile zur Dokumentation des Standards automatisiert aus dem XÖV-Fachmodell generiert. Hierbei handelt es sich um Teildokumente (zum Beispiel im OASIS DocBook-Format), die um manuell geschriebene Teildokumente ergänzt und zu einem Gesamtdokument zusammengesetzt werden. Das Gesamtdokument wird daraufhin automatisiert in das Spezifikationsdokument, z. B. im PDF-Format, überführt.
Version eines Inhalts: Eine Version eines Inhalts wird im XRepository zu dem jeweiligen Inhalt bereitgestellt. Sie besteht aus einer Reihe von Dateien, die den Entwicklungs- bzw. Fortschreibungsstand des Inhalts wiedergeben und diesen in unterschiedlichen Formaten zum Bezug abbilden.

Ein konkreter Stand der Entwicklung bzw. Fortschreibung eines Inhalts wird als Version des Inhalts bezeichnet, die mittels einer im Kontext des Inhalts eindeutigen Versionsbezeichnung, z. B. "2.0", gekennzeichnet wird.

Die Version eines Inhalts besitzt zur übergreifend eindeutigen Identifikation eine Versionskennung bestehend aus der Kennung des Inhalts und der Versionsbezeichnung sowie weitere versionsspezifische Metadaten, wie Angaben zur Gültigkeit oder Informationen zu Änderungen, die sich gegenüber der Vorversion ergaben.
XGenerator: Der XGenerator führt die Prüfung des XÖV-Fachmodells und die Generierung der Bestandteile eines XÖV-Standards aus dem XÖV-Fachmodell automatisiert durch. Die Vorgaben zur konkret durchzuführenden Prüfung und Generierung erhält der XGenerator mit den XÖV-Prüfanweisungen und XÖV-Übersetzungsanweisungen, die mit der XÖV-Produktionsumgebung bereitgestellt werden. Bei dem XGenerator handelt es sich um ein Produkt des XÖV-Standardisierungsrahmens.

Weitere Informationen hierzu finden Sie auf der XÖV-Dokumentationsplattform unter XGenerator.
XRepository: Das XRepository ist die Distributionsplattform des XÖV-Standardisierungsrahmens. Es unterstützt die Prozesse der Entwicklung und Bereitstellung eines Standards, seine XÖV-Zertifizierung wie auch seine operative Nutzung. Alle Bestandteile eines XÖV-Standards sowie die für den Datenaustausch notwendigen Artefakte wie Codelisten können über das XRepository bereitgestellt und bezogen werden.

Weitere Informationen hierzu finden Sie auf www.xrepository.de.
XSD-Schema: Ein XSD-Schema ist ein Schema der "XML Schema Definition Language" (kurz XSD) des World Wide Web Consortiums (W3C), mit dem die Strukturen und Inhalte von XML-Dokumenten geregelt werden. Jedes XSD-Schema beschreibt einen eindeutigen Namensraum und kann dabei aus mehreren XSD-Schema-Dateien bestehen.

XSD-Schemas sind zentrale Bestandteile eines XÖV-Standards. Sie dienen insbesondere der technischen Implementierung des Standards, z. B. dem Aufbau der Grundstrukturen eines Fachverfahrens und der Validierung aus- und eingehender Nachrichten.
W3C-Datentypen: Die Spezifikation der "XML Schema Definition Language" (kurz XSD) des World Wide Web Consortiums (W3C) definiert grundlegende Datentypen, wie date und string, auf die alle weiteren Datentypen eines XÖV-Standards direkt oder indirekt aufbauen. Sie stehen über die XÖV-Produktionsumgebung zur direkten Nutzung in einem XÖV-Fachmodell zur Verfügung.
XÖV: XÖV steht für "XML in der Öffentlichen Verwaltung".
XÖV-Dokumentationsplattform: Auf der XÖV-Dokumentationsplattform (XÖV docs) werden die Inhalte und Informationen zum XÖV-Standardisierungsrahmen, seiner Produkte und Releases sowie zu deren Betrieb und Support bereitgestellt.

Die Plattform finden Sie unter docs.xoev.de.
XÖV Good Practice: Good Practices sind Hinweise auf in der Praxis bewährte Namens- und Entwurfsmuster. Diese Hinweise sind ausschließlich als Empfehlungen auf mögliche Umsetzungsvarianten zu verstehen und sind nicht zertifizierungsrelevant.
XÖV-Notation classic: Die XÖV-Notation classic ist eine XÖV-Notation der XÖV-Modellierungssprache zur Spezifikation von XÖV-Fachmodellen und XÖV-konformen Codelisten-Fachmodellen. Sie basiert auf dem OMG/ISO Standard "Unified Modeling Language" (kurz UML) und erfordert die Nutzung eines UML-Modellierungswerkzeugs.
XÖV-Notation lite: Die XÖV-Notation lite ist eine XÖV-Notation der XÖV-Modellierungssprache zur Spezifikation von XÖV-Fachmodellen. Sie ist rein XML-basiert. Damit handelt es sich bei einem XÖV-Fachmodell in der Notation lite um ein XML-Dokument, das eine gültige Instanz des mit der XÖV-Produktionsumgebung bereitgestellten lite-XSD-Schemas ist.
XÖV-Bausteine: XÖV-Bausteine sind Bausteine, die durch die XÖV-Koordination originär betrieben bzw. konsolidiert und zur Nutzung in XÖV-Standards bereitgestellt werden. Alle XÖV-Bausteine, ausgenommen die XÖV-Codelisten, werden mit der XÖV-Bibliothek bereitgestellt. XÖV-Codelisten werden demgegenüber wie alle weiteren Codelisten über das XRepository bereitgestellt.
XÖV-Bibliothek: Die XÖV-Bibliothek stellt für alle XÖV-Vorhaben den zentralen Bezugspunkt für die XÖV-Bausteine dar, ausgenommen die XÖV-Codelisten, welche im XRepository bereitgestellt werden. Sie erlaubt damit eine einheitliche Einbindung und Nutzung der XÖV-Datentypen und globalen Eigenschaften(gruppen) inklusive der Inhalte zu etabliertern Datenmodellen in XÖV-Standards.

Veröffentlicht wird die XÖV-Bibliothek, den XÖV-Prinzipien zur Entwicklung von Standards folgend, in der Form eines Modells, welches in XÖV-Fachmodelle als externes Modell eingebunden wird.

Weitere Informationen hierzu finden Sie auf docs.xoev.de/bibliothek/übersicht.
XÖV-Codeliste: Eine XÖV-Codeliste ist eine zum Codelisten-Handbuch konforme Codeliste, die durch die XÖV-Koordination betrieben und bereitgestellt wird. Aus inhaltlicher Sicht werden mit den XÖV-Codelisten insbesondere etablierte internationale Normen wie beispielsweise die ISO 3166 (Staaten) oder ISO 639 (Sprachen) umgesetzt, um deren Nachnutzung im XÖV-Kontext zu harmonisieren.
XÖV-Datentypen und globale Eigenschaften(gruppen): XÖV-Datentypen und globale Eigenschaften(gruppen) stellen fundamentale, meist fachunabhängig nutzbare XÖV-Bausteine dar, deren Einsatz in unveränderter Form in allen XÖV-Standards vorgesehen ist. Sie liegen als XML-Datentypen, globale XML-Elemente, XML-Attribute und XML-Gruppen in veröffentlichten XSD-Schemas vor und stehen in der XÖV-Bibliothek zur direkten Nutzung in einem XÖV-Fachmodell zur Verfügung.
XÖV-Fachmodell: Ein XÖV-Fachmodell und seine Inhalte sind gemäß der XÖV-Modellierungssprache und den zugehörigen XÖV-Notationen spezifiziert und konform zu den XÖV-Namens- und Entwurfsregeln. Es hält alle Informationen, die für die automatisierten Erstellung der obligatorischen Bestandteile eines XÖV-Standards mittels XGenerator und XÖV-Produktionsumgebung erforderlich sind.
XÖV-Handbuch: Das Handbuch zur Entwicklung XÖV-konformer Standards (kurz XÖV-Handbuch) umfasst alle für ein XÖV-Vorhaben relevanten Informationen zum XÖV-Standardisierungsrahmen. In ihm sind neben den XÖV-Regelungen und -Vorgaben das XÖV-Angebot in Form von Bausteinen, Infrastrukturkomponenten und Werkzeugen sowie die Methodik zur Nutzung des Angebots beschrieben. Das XÖV-Handbuch richtet sich an alle Fach- und Führungskräfte, die Vorhaben zur Entwicklung von Datenübertragungsstandards in der öffentlichen Verwaltung begleiten, bearbeiten oder verantworten.

Weitere Informationen hierzu finden Sie auf docs.xoev.de/xoev-handbuch/übersicht.
XÖV-Konfiguration: Eine Voraussetzung für die Erstellung eines XÖV-Standards ist die Verwendung einer gültigen XÖV-Konfiguration. Diese besteht, ausgehend von einer bestimmten Version des XÖV-Handbuchs, aus einer Kombination von XÖV-Produktionsumgebung, XGenerator und Codelisten-Handbuch in kompatiblen Versionen.

Die Übersicht der aktuell gültigen Konfigurationen ist auf der XÖV-Dokumentationsplattform veröffentlicht unter docs.xoev.de/konfigurationen/übersicht.
XÖV-Konformität: Die XÖV-Konformität eines Standards wird im Rahmen der XÖV-Zertifizierung durch die XÖV-Koordination festgestellt. Sie stellt ein Qualitätsmerkmal eines XÖV-Standards dar, das die Einhaltung der XÖV-Konformitätskriterien bescheinigt.
XÖV-Konformitätskriterien: XÖV-Konformitätskriterien sind konkrete Prüfkriterien, die ein XÖV-Standard erfüllt. Sie sind in die vier Bereiche "Bereitstellungspflichten", "Auskunftspflichten der Standardentwickler und -betreiber", "Wiederverwendung der XÖV-Bausteine" sowie "Technische Kriterien" unterteilt. Dabei werden dabei die Verbindlichkeitsstufen MUSS und SOLL unterschieden.
XÖV-Koordination: Die XÖV-Koordination ist im Auftrag des IT-Planungsrats Herausgeberin des XÖV-Standardisierungsrahmens. Dies umfasst sowohl die Herausgabe und den Betrieb zugehöriger Regelungen, Bausteine, Werkzeuge und Infrastrukturkomponenten als auch die Betreuung von XÖV-Vorhaben inklusive der XÖV-Zertifizierung von Standards. Die Aufgaben der XÖV-Koordination werden derzeit durch die KoSIT wahrgenommen.
XÖV-Modellierung: XÖV-Modellierung ist die Spezifikation von Informationen zu einem Standard oder einer Codeliste mit den Mitteln der XÖV-Modellierungssprache in ein XÖV-Fachmodell oder ein XÖV-konformes Codelisten-Fachmodell.
XÖV-Modellierungssprache: Die XÖV-Modellierungssprache setzt sich aus den Modellierungssprachen zur Spezifikation von XÖV-Fachmodellen und von XÖV-konformen Codelisten zusammen, die mit dem XÖV-Handbuch und dem Codelisten-Handbuch beschrieben sind. Mit den XÖV-Notationen classic und lite werden zwei Alternativen zur Spezifikation von XÖV-Fachmodellen angeboten. Für den Bereich Codelisten kann die XÖV-Notationen classic oder die des OASIS-Standards Genericode genutzt werden.
XÖV-Namens- und Entwurfsregeln: Die XÖV-Namens- und Entwurfsregeln (siehe Kapitel 6, ) lenken die technische Ausgestaltung eines XÖV-Standards während seiner Spezifikationsphase, in der das Fachmodell des Standards in ein XÖV-Fachmodell überführt wird. Ihre Berücksichtigung wird durch das Konformitätskriterium „K-10 (MUSS): Einhaltung der XÖV-Namens- und Entwurfsregeln“ gefordert.
XÖV-Notation: Die Spezifikation von Informationen zu einem Standard oder einer Codeliste mit den Mitteln der XÖV-Modellierungssprache muss in einer konkreten XÖV-Notation erfolgen. Mit den XÖV-Notationen classic und lite werden zwei gleichberechtigte Alternativen für den Bereich der Spezifikation von XÖV-Fachmodellen angeboten. XÖV-konforme Codelisten-Fachmodelle können in der Notation classic oder mit der Notation des OASIS-Standards Genericode spezifiziert werden.
XÖV-Produkt: XÖV-Produkte sind einzelne oder zusammengefasste Komponenten des XÖV-Standardisierungsrahmens, wie beispielsweise der XGenerator, die XÖV-Produktionsumgebung oder das XÖV-Handbuch. Auf der XÖV-Dokumentationsplattform werden neben grundlegenden Informationen zu allen XÖV-Produkten auch Informationen zum Bezug und der Release-Planung gegeben.
XÖV-Produktionsumgebung: Die XÖV-Produktionsumgebung (kurz XÖV-PU) stellt die zentrale Umgebung dar, in der die Inhalte eines XÖV-Standards spezifiziert und produziert werden. Sie umfasst auf der einen Seite die Inhalte zur Verwendung der XÖV-Modellierungssprache in der Notation classic und lite. Auf der anderen Seite bringt sie alle Informationen mit, auf deren Basis das XÖV-Fachmodell automatisiert geprüft und übersetzt werden kann.

Die XÖV-PU wird analog und konsistent zum XÖV-Handbuch fortgeschrieben und über die XÖV-Dokumentationsplattform in unterschiedlichen Editionen für jede XÖV-seitig unterstützte Modellierungsumgebung bereitgestellt.
XÖV-Profil: Das XÖV-Profil ist Teil der XÖV-Produktionsumgebung und dient der Anwendung der XÖV-Notation classic. In diesem Rahmen umfasst es die XÖV-Stereotypen und W3C-Datentypen zur Nutzung im UML-basierten XÖV-Fachmodell. Darüber hinaus enthält es Anweisungen zur automatisierten Überprüfung einer konsistenten Nutzung der Stereotypen durch den XGenerator.

XÖV-Prüfanweisungen: XÖV-Prüfanweisungen ermöglichen sowohl den Standardisierungsvorhaben als auch der XÖV-Zertifizierungsstelle eine Teilmenge der XÖV-Regelungen mittels XGenerator auf der Basis der XÖV-Produktionsumgebung automatisiert zu prüfen.
XÖV-Rahmenwerk: siehe XÖV-Standardisierungsrahmen
XÖV-Regelungen: Die XÖV-Regelungen umfassen die XÖV-Konformitätskriterien und die XÖV-Namens- und Entwurfsregeln. Mit den XÖV-Regelungen wird insbesondere das Ziel verfolgt, das dem XÖV-Entwicklungsansatz zugrundeliegende Prinzip der Wiederverwendung bestehender Lösungen in der praktischen Arbeit der XÖV-Vorhaben zu verankern. Sie geben den Vorhaben eine praktische Handlungsgrundlage bei der Verwendung der mit dem XÖV-Standardisierungsrahmen bereitgestellten Komponenten und helfen dabei gleichzeitig, Ergebnisse der Standardisierung strukturell zu vereinheitlichen und somit deren (Wieder-)Verwendung zu vereinfachen.
XÖV-Standard: Als XÖV-Standard wird ein Standard bezeichnet, dessen XÖV-Konformität von der XÖV-Koordination zertifiziert wurde.
XÖV-Standardisierungsrahmen: Der durch die XÖV-Koordination bereitgestellte XÖV-Standardisierungsrahmen (kurz auch XÖV-Rahmenwerk) ermöglicht die praktische Umsetzung der einzelnen Schritte des XÖV-Entwicklungsprozesses. Er unterstützt damit XÖV-Vorhaben umfassend von der ersten systematischen Ermittlung der fachlichen Anforderungen bis zur letztendlichen Bereitstellung eines XÖV-Standards. Der Standardisierungsrahmen besteht aus einer Reihe von aufeinander abgestimmten XÖV-Regelungen, XÖV-Werkzeugen, XÖV-Bausteinen und XÖV-Infrastrukturkomponenten.
XÖV-Starterpaket: Das XÖV-Starterpaket stellt für neue XÖV-Vorhaben einen Einstiegspunkt in die praktische Entwicklung eines XÖV-Standards dar. Es besteht in verschiedenen Editionen für die XÖV-Notationen classic und lite aus einem XÖV-Fachmodell mit beispielhaften Inhalten, einer aktuellen XÖV-Konfiguration, einem beispielhaften DocBook-Dokument, welches die Grundlage des Spezifikationsdokuments zum Starterpaket darstellt und einem DocBook-Zubehör zur automatisierten Erstellung des Spezifikationsdokuments im PDF-Format.
XÖV-Stereotyp: Stereotypen ermöglichen die Zuordnung von Klassifikationen und Eigenschaften zu Elementen eines UML-Modells. Die im Rahmen des XÖV-Profils definierten Stereotypen dienen der Anwendung der XÖV-Modellierungssprache in der XÖV-Notation classic und in diesem Rahmen der technischen Anreicherung eines Fachmodells um Informationen zur Ausgestaltung der Bestandteile eines Standards, insbesondere seiner XSD-Schemas. Die Anwendung der XÖV-Stereotypen steuert damit die Behandlung der Modellinhalte durch den XGenerator, z. B. ob eine UML-Klasse in einen XML-Datentyp oder ein XML-Element resultiert.
XÖV-Vorhaben: Im Rahmen eines XÖV-Vorhabens wird ein XÖV-Standard zunächst entwickelt und dann betrieben. Das Vorhaben umfasst damit den gesamten Lebenszyklus des Standards.
XÖV-Zertifizierung: Die XÖV-Zertifizierung der XÖV-Konformität durch die prüfende Stelle der XÖV-Koordination bestätigt die formale Qualität eines XÖV-Standards.
XÖV-Zertifizierungsstelle: Die XÖV-Zertifizierungsstelle bietet allen XÖV-Vorhaben die Möglichkeit, ihren Standard gemäß den XÖV-Konformitätskriterien und den damit einhergehenden XÖV-Namens- und Entwurfsregeln zertifizieren zu lassen.
XÖV-Übersetzungsanweisungen: XÖV-Übersetzungsanweisungen bestimmen als Teil der XÖV-Produktionsumgebung die Überführung eines XÖV-Fachmodells und der darin modellierten Inhalte in die Bestandteile eines XÖV-Standards. Sie werden durch den XGenerator automatisiert ausgeführt.

Anhang A: Sprachelemente zu Konfiguration

In der folgenden Tabelle werden die Sprachelemente zur Konfiguration des XÖV-Fachmodells beschrieben und den Notationselementen in classic und XÖV lite zugeordnet. In classic betrifft dies die Eigenschaften des Stereotyps xsdXModel, in XÖV lite die Kindelemente des Elements konfiguration.xoev-fachmodell.

Tabelle 21. Sprachelemente zu `Konfiguration des XÖV-Fachmodells`
fassungVom		[0..1]
Datum der Fassung des XÖV-Fachmodells. Die Information dient ausschließlich Dokumentationszwecken.	`classic`	`fassungVom`
	`lite`	`fassungVom`
namespace		[0..1]
Bestimmt einen Standardnamensraum, der für alle Schemapakete gilt, in denen der Namensraum nicht explizit angegeben ist.	`classic`	`namespace`
	`lite`	`namespace`
prefix		[0..1]
Bestimmt ein Standardpräfix, das für alle Schemapakete gilt, in denen das Präfix nicht explizit angegeben ist.	`classic`	`prefix`
	`lite`	`prefix`
schemaLocationBase		[0..1]
Der Basispfad der Schema Locations. Der physische Speicherort (URL inklusive eines abschließenden Schrägstriches (/) exklusive Dateiname), an dem die XSD-Schemas später gefunden werden können. Bildet zusammen mit dem Namen der Schemadatei eine vollständige Schema Location, sofern für das jeweilige Schemapaket eine Schema Location nicht explizit angegeben ist.	`classic`	`schemaLocationBase`
	`lite`	`schemaLocationBase`
elementFormDefault		[0..1]
Mittels dieser Eigenschaft kann für alle XSD-Schemas die standardmäßige Qualifizierung der XML-Elemente vorgegeben werden, also der Wert für das XML Schema-Attribut elementFormDefault. Falls der Eigenschaft kein Wert oder der Wert 'qualified' zugewiesen ist, gelten die XML-Elemente als qualifiziert. Die Modell-weit geltende Vorgabe zur Qualifizierung von XML-Elementen kann sowohl auf Schemapaket-Ebene als auch auf XML-Element-Ebene überschrieben werden.	`classic`	`elementFormDefault`
	`lite`	`elementFormDefault`
standardeinstellungEigenschaften		[0..1]
Bestimmt, ob Eigenschaften, die mit keinem Stereotyp annotiert sind, als XML-Elemente umgesetzt werden (Wert 'Element' bzw. kein Wert) oder keine implizite Deutung erfolgen soll (Wert 'keine').	`classic`	`standardeinstellungEigenschaften`
	`lite`	`standardeinstellungEigenschaften`
xsdGlobalElementNamePrefix		[0..1]
Legt ein Präfix fest, das allen Namen globaler Elemente bei ihrer Umsetzung in XML Schema vorangesetzt wird. Namen von Nachrichten sind hiervon nicht betroffen.	`classic`	`xsdGlobalElementNamePrefix`
	`lite`	`xsdGlobalElementNamePrefix`
xsdGlobalElementNameSuffix		[0..1]
Legt ein Suffix fest, das allen Namen globaler Elemente bei ihrer Umsetzung in XML Schema hintangestellt wird. Namen von Nachrichten sind hiervon nicht betroffen.	`classic`	`xsdGlobalElementNameSuffix`
	`lite`	`xsdGlobalElementNameSuffix`
xsdNamedTypeNamePrefix		[0..1]
Legt ein Präfix fest, das allen Namen benannter Datentypen bei ihrer Umsetzung in XML Schema vorangesetzt wird.	`classic`	`xsdNamedTypeNamePrefix`
	`lite`	`xsdNamedTypeNamePrefix`
xsdNamedTypeNameSuffix		[0..1]
Legt ein Suffix fest, das allen Namen benannter Datentypen bei ihrer Umsetzung in XML Schema hintangehängt wird. Standardwert ist "Type".	`classic`	`xsdNamedTypeNameSuffix`
	`lite`	`xsdNamedTypeNameSuffix`
typDesCodeElements		[0..1]
An dieser Stelle können die Grundeinstellungen für Code-Datentypen vorgenommen werden, die für jeden Code-Datentyp des Standards gelten, in dem die Einstellungen nicht überschrieben werden. Es wird der Typ des Elements code für nicht schemavalidierte Codelisten (Code-Typen 2 bis 4) bestimmt. Standardwert ist "xs:token".	`classic`	`typDesCodeElements` für die UML-Stereotypen xoevCodeTyp1, xoevCodeTyp2, xoevCodeTyp3 und xoevCodeTyp4
	`lite`	`typDesCodeElements`
nutzungNameElement		[0..1]
An dieser Stelle können die Grundeinstellungen für Code-Datentypen vorgenommen werden, die für jeden Code-Datentyp des Standards gelten, in dem die Einstellungen nicht überschrieben werden. Es wird bestimmt, ob das Element name nicht, optional oder mantorisch eingesetzt werden soll. Standardwert ist "keineNutzung".	`classic`	`nameElement` für die UML-Stereotypen xoevCodeTyp1, xoevCodeTyp2, xoevCodeTyp3 und xoevCodeTyp4
	`lite`	`nutzungNameElement`
benannterCodelistenDatentyp		[0..1]
An dieser Stelle können die Grundeinstellungen für Code-Datentypen vorgenommen werden, die für jeden Code-Datentyp des Standards gelten, in dem die Einstellungen nicht überschrieben werden. Es wird bestimmt, ob im Falle einer schemavalidierten Codelistenversion (Code-Typ 1) diese als benannter Datentyp (Wert "true" bzw. keinem Wert) oder anonymer Typ (Wert "false") umgesetzt werden soll.	`classic`	`benannterCodelistenDatentyp` für den Stereotyp xoevCodeTyp1
	`lite`	`benannterCodelistenDatentyp`
codesSchemavalidiert		[0..1]
An dieser Stelle können die Grundeinstellungen für Code-Datentypen vorgenommen werden, die für jeden Code-Datentyp des Standards gelten, in dem die Einstellungen nicht überschrieben werden. Es wird bestimmt, ob die genutzte Codelistenversion schemavalidiert werden soll (Code-Typ 1 bei Wert "true" bzw. keinem Wert) oder nicht (Code-Typ 2 bei Wert "false").	`classic`
	`lite`	`codesSchemavalidiert`

Anhang B: Regelungen zur Bildung von Kennungen

Einheitliche Regelungen zur Bildung von Kennungen unterstützen Herausgeber bei der Vergabe eindeutiger Kennungen für ihre Inhalte und unterstützt so die gemeinschaftliche Verwendung dieser Kennungen. Kennungen finden Verwendung zur eindeutigen Identifizierung von Standards, Codelisten und XÖV-Bausteinen sowie deren Versionen.

Die Kennung eines Inhalts wird nach XÖV-Konvention in der URN-Syntax gebildet. Die allgemeine URN-Syntax ist mit RFC8141 der Internet Engineering Task Force (IETF) vorgegeben.^[6] Mit der URN-Syntax soll die globale Eindeutigkeit von Kennungen sichergestellt werden. Hierzu ist der URN in einen globalen und einen lokalen Teil unterteilt. Der globale Teil stellt die globale Eindeutigkeit sicher und verweist auf einen Namensraum mit einer spezifischen Syntax, die die Bildung des lokalen Teils regelt und somit die lokale Eindeutigkeit sicherstellt.

Die XÖV-Koordination bietet den globalen Teil urn:xoev-de: und eine zugehörige Syntax zur Bildung des lokalen Teils an. Die Verwendung des globalen Teils ist für Standards und XÖV-Bausteine und deren Versionen verpflichtend. Mit der Verwendung des globalen Teils ist die Verwendung der im Folgenden beschriebenen, zugehörigen Syntax obligatorisch. Für Codelisten und deren Versionen wird die Verwendung des globalen Teils empfohlen.

Die Kennung eines Inhalts, der den globalen Teil urn:xoev-de: verwendet, ist wie folgt aufgebaut:

urn:xoev-de:Herausgeber:Inhaltsart:Name

Die inhaltlichen Bestandteile der Kennung sind vom Herausgeber eines Inhalts nach den folgenden Regelungen auszugestalten.

Herausgeber: Der variable Teil Herausgeber stellt den Namensraum des Herausgebers des Inhalts in Kleinschreibung dar. Die zur Beschreibung des Namensraums erlaubten Zeichen sind a-z, 0-9, - und :. Das Zeichen - wird dabei ausschließlich zur Worttrennung verwendet (z. B. kraftfahrt-bundesamt). Einzelne Namensraumbestandteile werden durch das Zeichen : getrennt (z. B. bund:itzbund).
Inhaltsart: Der variable Teil Inhaltsart beschreibt die Art des Inhalts, für den die Kennung genutzt wird. Erlaubte Angaben zur Beschreibung von Inhaltsarten sind codeliste, standard und baustein. Letztere umfasst alle Arten von XÖV-Bausteinen, die mit der XÖV-Bibliothek zur Nutzung bereitgestellt werden.
Name: Der variable Teil Name stellt den technischen Namen (siehe Tabelle 22, “Metadaten eines XÖV-Standards und seiner Versionen”) des Inhalts dar (z. B. xinneres.xpersonenstand). Die zur Beschreibung des Namens erlaubten Zeichen sind a-z, 0-9, - und .. Das Zeichen . wird dabei ausschließlich zur Klassifikation verwendet (z. B. religion.steuererhebend). Das Zeichen - wird ausschließlich zur Worttrennung verwendet (z. B. religion.nicht-steuererhebend).

Die Kennung einer Version eines Inhalts wird, wie im Folgenden dargestellt, gebildet aus der Kennung des zugehörigen Inhalts, dem verbindenden Zeichen _ und der Versionsangabe.

urn:xoev-de:Herausgeber:Inhaltsart:Name_Version

Version: Die zur Beschreibung der Version erlaubten Zeichen sind a-z, 0-9, - und .. Versionen, die nicht den Vorgaben entsprechen, müssen in diese Form überführt werden.

Anhang C: Metadaten eines XÖV-Standards

Die folgende Tabelle gibt einen vollständigen Überblick über die Metadaten eines Standards und seiner Versionen, die im XÖV-Fachmodell gehalten und fortgeschrieben werden können oder müssen. Weitere Metadaten insbesondere zu den Status von Standards und Versionen können mit der Bereitstellung des XÖV-Fachmodells direkt im XRepository gepflegt werden. Informationen hierzu sind unter Hilfe im XRepository gegeben.

Tabelle 22. Metadaten eines XÖV-Standards und seiner Versionen
Name [Häufigkeit]	Beschreibung
Metadaten zum Standard
Name (lang) [1]	Der Name (lang) ist die `sprechende` Bezeichnung eines Standards.
Name (kurz) [1]	Der Name (kurz) ist die `sprechende` Kurzbezeichnung eines Standards. Dieser Name wird beispielsweise im XRepository in Listendarstellungen von Inhalten verwendet oder kann zur Bezeichnung des Standards in Texten (Spezifikationsdokument) verwendet werden.
Name (technisch) [1]	Neben den Namen (lang) und Namen (kurz) besitzt ein Standard einen technischen Namen. Dieser Name soll `sprechend` und gleichzeitig zur technischen Verarbeitung optimiert sein. In der Regel ist der technische Name vom Namen (kurz) abgeleitet. Die zur Beschreibung dieses Namens erlaubten Zeichen sind `a-z`, `A-Z`, `0-9`, `-` und `.`. Das Zeichen `.` wird dabei ausschließlich zur Klassifikation verwendet. Das Zeichen `-` wird ausschließlich zur Worttrennung verwendet.
Kennung [1]	Mittels einer Kennung wird ein Standard versionsübergreifend eindeutig identifiziert. Die Regelungen dazu sind in Anhang B, dokumentiert.
Beschreibung [1]	Zu einem Standard liegt eine Beschreibung in Form eines unformatierten Fließtextes vor.
Metadaten zur Version eines Standards
Version [1]	Die Version kennzeichnet einen definierten Stand der Entwicklung oder Fortschreibung eines Standards. Sie wird zur Bildung der Kennung der Version des Standards genutzt.
Beschreibung [0..1]	Zur Version eines Standards kann eine Beschreibung in Form eines unformatierten Fließtextes vorliegen.
Version XÖV-Handbuch [1]	Die Version des XÖV-Handbuchs, zu dessen Regelungen die Version eines Standards konform ist.
Version XÖV-Produktionsumgebung [1]	Die Version der XÖV-Produktionsumgebung, mit dem das XÖV-Fachmodell der Version eines Standards verarbeitet und die Bestandteile der Version des Standards erzeugt wurden.
Name Modellierungswerkzeug [1]	Der Name des Modellierungswerkzeugs, mit dem das XÖV-Fachmodell der Version eines Standards erstellt wurde.
Version Modellierungswerkzeug [1]	Die Version des Modellierungswerkzeugs, mit dem das XÖV-Fachmodell der Version eines Standards erstellt wurde.

Anhang D: Verwendete Standards

Die Methoden und Produkte des XÖV-Standardisierungsrahmens sowie die auf der Basis des Rahmenwerks entwickelten XÖV-Standards nutzen die in der folgenden Tabelle dargestellten Normen, Standards und Anwendungen.

Tabelle 23. Genutzte Standards in der Übersicht
Norm / Standard / Anwendung	Herausgeber
Standards des XÖV-Standardisierungsrahmens
Model Driven Architecture (MDA)	OMG
Unified Modeling Language (UML)	OMG
XML Metadata Interchange^[7] (XMI)	OMG
Extensible Markup Language (XML)	W3C
XML Schema Definition Language (XSD)	W3C
DocBook	OASIS
Genericode	OASIS
Extensible Stylesheet Language Transformation (XSLT)	W3C
XML Path Language (XPath)	W3C
Schematron	ISO/IEC
Webservice Description Language (WSDL)	W3C
RFC 8141 (URN Syntax)	IETF
Lateinische Zeichen in Unicode	KoSIT
Zeichen und definierte Zeichensequenzen in Unicode für die elektronische Verarbeitung von Namen und den Datenaustausch in Europa (DIN 91379)	DIN
Eclipse Modeling Framework (EMF)
Java	Oracle
Standards eines XÖV-Standards
Unified Modeling Language (UML)	OMG
Extensible Markup Language (XML)	W3C
XML Schema Definition Language (XSD)	W3C
DocBook	OASIS
Genericode	OASIS
Schematron	ISO/IEC
Webservice Description Language (WSDL)	W3C

Anhang E: Versionshistorie

In diesem Anhang werden je Release des XÖV-Handbuchs die Bereiche beschrieben, in denen Veränderungen oder Ergänzungen vorgenommen worden sind.

Release 4.0.0

Regelung: K-11 (SOLL) Nutzung der XÖV-Kernkomponenten wurde gestrichen
Regelung: K-12 (SOLL) Nutzung der XÖV-Datentypen wurde gestrichen
Regelung: K-16 (SOLL) Nutzung der Bausteine der XÖV-Bibliothek wurde neu eingeführt
Regelung: Ausgliederung aller NDRs mit Verbindlichkeit EMPFEHLUNG in Good Practice
Methodik: Dekommisionierung von Kernkomponenten und zugehöriger Methodik
Methodik: Einführung der XÖV-Modellierungssprache und zugehöriger Sprachkonzepte
Methodik: Einführung der Notation lite und XÖV classic zur Spezifikation von XÖV-Fachmodellen
Methodik: Einführung eines Features zur Spezifikation von Beispielwerten
Methodik: Abschnitt zu XÖV-Adaptern ersatzlos gestrichen
Methodik: Grundlegende Überarbeitung des Glossars

Release 3.0.2

Im Abschnitt 8.3.2. “Modellierung spezieller Anforderungen”, Unterabschnitt “Bestimmung der zu nutzenden Beschreibungsspalte” wurde das Vorgehen zur Angabe der gewählten Beschreibungsspalte präzisiert. (Issue Public 51)

Release 3.0.1

In der Beschreibung der NDR-33 “Codelisten konform zu den Regelungen des Codelisten-Handbuchs” wurde eine Aussage zum Umgang mit bestehenden und neuen Codelistenversionen aufgenommen. (Issue Public 45)
Redaktionelle Anpassungen wurden vorgenommen.

Release 3.0

Wesentliche Änderungen des XÖV-Standardisierungsrahmens betreffen die Vorbereitung der XÖV-Produkte für ihren zusätzlichen Einsatz in dem open-Source-Modellierungswerkzeug Papyrus sowie die Umsetzung und Dokumentation einer vereinfachten, modellgetriebenen Entwicklungsmethodik zur Spezifikation und Produktion eines XÖV-Standards. Die aktualisierte Methodik wird hauptsächlich im neu geschaffenen XÖV-Primer-Dokument beschrieben, welches einen leichten Einstieg in die praktische Entwicklung eines XÖV-Standards ermöglichen soll. In das XÖV-Handbuch wurden an den erforderlichen Stellen Hinweise auf das Modellierungswerkzeug Papyrus und den XÖV-Primer aufgenommen.
In der Erläuterung der NDR-3 wurde der Verweis auf den Stereotyp xsdGlobalElement entfernt, da dieser nicht mehr zur Annotation einer Nachricht benötigt wird.
Der Begriff “XÖV-Primer” wurde in das Glossar aufgenommen.
Die Kurzbeschreibung zu NDR-9 in der Tabelle “Übersicht der Regeln und Empfehlungen” wurde geändert in “Umgang mit speziellen Anforderungen an die Nutzung von Codelisten”. (Issue Public 33)
Im Abschnitt “XÖV-Datentypen” wurde ein Bezug zur neu eingeführten XÖV-Basisnachricht hergestellt.

Release 2.4

In Abschnitt 8.3.2. “Modellierung spezieller Anforderungen” wurde der neue Abschnitt “Nutzung mehrsprachiger Codelisten” aufgenommen. (Issue 43)
In Abschnitt 2.3.2. “XGenerator” wurde der Verweis auf die XMI-Version “Eclipse UML2 v4.x” geändert in “Eclipse UML2 v5.x”. (Issue 45)
Im Appendix B “Glossar” Hinweis auf die Abschaltung des Genericoders eingefügt. (Issue 42)

Release 2.3.1

Abschnitt 2.2.1. "XÖV-Datentypen" und Kapitel 6. "Nutzung von XÖV-Datentypen" wurden um Aussagen zum neuen XÖV-Adapter "XML namespace" erweitert. (Issue 37)
In der NDR-Tabelle “Übersicht der Regeln und Empfehlungen” wurde die Angabe zur Verbindlichkeit der NDR-12 korrigiert. Sie entspricht nun der tatsächlichen Verbindlichkeit der NDR (EMPFEHLUNG). (Issue 38)

Release 2.3

In den Konformitätskriterien K-1 und K-15 wurden die Prüfgrundlage und der Prüfinhalt aktualisiert. Dabei wurden Aussagen zum XÖV-Steckbrief entfernt. (Issue 3)
In der Beschreibung von NDR-33 wurde ein redundanter Absatz entfernt. (Issue 4)
Aus der Tabelle 4.1. “Übersicht der Metadatenelemente eines Standards und seiner Versionen” wurden die Metadatenelemente entfernt, die automatisiert erhoben oder im XRepository eingetragen werden. (Issue 8)
NDR-34 (Modellierung von Codelistenversionen als benannte Typen) wurde neu erstellt (Issue 10).
Prüfinhalt und Begründung wurden in Konformitätskriterium K-9 redaktionell angepasst. (Issue 11)
NDR-24 wurde hinsichtlich der Möglichkeiten zur Wiederverwendung generischer Nachrichteneigenschaften offener gestaltet. (Issue 12)
Im Kapitel “Nutzung von Codelisten” wurden die Abschnitte “Codelisten im XÖV-Fachmodell”, “Kennzeichnung über Code-Typ 4 genutzter Codelisten(versionen)” und “Kennzeichnung der Nutzung von Codelisten ohne Code-Datentyp” neu aufgenommen. Aufgrund der neuen NDR-34 wurden darüber hinaus die Beispiele auf benannte Typen für Codelistenversionen umgestellt und der Abschnitt “Nutzung von Codelistenversionen als anonyme Datentypen” neu aufgenommen. Der Abschnitt “Nutzung von Codelistenversionen als benannte Datentypen” wurde grundlegend inhaltlich überarbeitet. Die Abschnitte wurden neu angeordnet. (Issue 26)
NDR-33 wurde bezüglich der neuen Codelisten-Methodik konkretisiert. (Issue 28)
Auf die XÖV-Webseite "Gültige XÖV-Konfigurationen" wird nun im einleitenden Text des Abschnitts 4.3. “XÖV-Namens- und Entwurfsregeln” verwiesen. Die Einzelverweise in den jeweiligen NDR-Abschnitten wurden entfernt. (Issue 29)

Release 2.2

In Abschnitt “Verwendete Standards” wurde die Tabelle aktualisiert.
In Abschnitt “Ansprechpartner und Mitwirkende” wurde die Tabelle aktualisiert.
Das Kapitel “Einleitung” wurde redaktionell angepasst.
Das gesamte Handbuch wurde aufgrund der Ablösung des InteropBrowsers durch die Interopmatrix (hauptsächlich redaktionell) überarbeitet.
Der Abschnitt “XÖV-Bausteine” (im Abschnitt “XÖV-Standardisierungsrahmen”) wurde redaktionell angepasst.
Der Abschnitt “XÖV-Datentypen” (im Abschnitt “XÖV-Bausteine”) wurde aufgrund neuer Datentypen überarbeitet und erweitert.
Der Abschnitt “XÖV-Codelisten” (im Abschnitt “XÖV-Bausteine”) wurde inhaltlich überarbeitet.
Der Abschnitt “InteropBrowser” (im Abschnitt “Werkzeuge”) wurde entfernt.
Der Abschnitt “XGenerator” (im Abschnitt “Werkzeuge”) wurde bzgl. der unterstützten XMI-Version konkretisiert.
Der Abschnitt “XRepository” (im Abschnitt “Infrastruktur”) wurde um Aussagen zur Interopmatrix erweitert.
Das Konformitätskriterium K-4 wurde um die Anforderung ergängt, dass alle durch den Standard genutzten Codelisten, wenn sie durch den Standard herausgegeben werden, im XRepository veröffentlicht sein müssen.
Konformitätskriterium K-6 und K-7 wurden aufgrund der Ersetzung des XÖV-Steckbriefs durch direkte Angaben im XRepository überarbeitet.
In Konformitätskriterium K-12 wurde die Vorgabe zur Nutzung der jeweils aktuellen Version gestrichen.
Das Konformitätskriterium K-13 “Nutzung von Codelisten” wurde inhaltlich aktualisiert.
Konformitätskriterium K-15 wurde redaktionell angepasst.
In Abschnitt “Prüfung der XÖV-Konformität” wurde die Aussage zu Canonical XMI gestrichen.
In Abschnitt “XÖV-Spezifikations- und Produktionsprozess” wurde Aufzählungspunkt 3. um weitere Bestandteile ergänzt.
An allen Stellen wurden im Fließtext die spitzen Klammern um Stereotyp-Namen entfernt.
Abschnitt “Produktion eines XÖV-Standards” wurde um Genericode-Elemente und weitere Elemente als Überführungsergebnis ergänzt.
In Abschnitt “Erstellung des Spezifikationsdokuments” wurde ein Beispiel hinzugefügt.
NDR-1 wurde um Aussagen zu “Strukturen” bereinigt.
In NDR-2 wurden in Aufzählungspunkt a. Vorgaben zum Namen des Modells gestrichen und in Aufzählungspunkt b. Codelisten-Modelle aufgenommen. Darüber hinaus wurde das Beispiel aktualisiert.
In NDR-5 wurde eine Vorgabe zur Benennung des Modells ergänzt.
NDR-8 “Versionsübergreifend eindeutige Codes in Codelisten” wurde aufgrund ihrer Überführung in das Codelisten-Handbuch gestrichen.
In Abschnitt “XÖV-Namens- und Entwurfsregeln” wurde der Abschnitt “Namen” umbenannt in “Namen für XML-Attribute, -Elemente und -Typen”.
NDR-10 “Konsistente Namen in XÖV-Fachmodell und XML Schema-Definitionen” wurde gestrichen, da sie durch die aktualisierte NDR-1 abgedeckt ist.
NDR-12 wurde in eine Empfehlung überführt.
In NDR-18 wurde bzgl. der Nutzung des technischen Namens aktualisiert.
NDR-22 wurde hinsichtlich Konsistenz von Codelisten in XÖV-Fachmodell und XRepository konkretisiert.
NDR-33 “Codelisten konform zu den Regelungen des Codelisten-Handbuchs” wurde neu erstellt.
NDR-31 wurde um eine Aussage zum Versionierungskonzept ergänzt und das enthaltene Beispiel aktualisiert.
Das Kapitel “XÖV-Bibliothek” wurde redaktionell überarbeitet.
Der Abschnitt “Datentypen der KoSIT” wurde aufgrund einer neuen Codelisten-Methodik im Bereich “Ableitung von einem XÖV-Datentyp über eine XML Schema-Restriktion” überarbeitet und um den Bereich “Implizite Nutzung des XÖV-Datentyps Code.” ergänzt.
In Abschnitt “Datentypen anderer Standards und Normen (XÖV-Adapter)” wurden die Beispiele ausgetauscht und der Abschnitt redaktionell angepasst.
Die Abbildung “Einschränkung des Datentyps einer Basiskernkomponente (xoevBCC)” wurde aktualisiert.
Das Kapitel “Nutzung von Codelisten” wurde aufgrund einer neuen Codelisten-Methodik komplett überarbeitet. Teile des Kapitels wurden in das Codelisten-Handbuch verlagert.
Der Anhang “Mitwirkende” wurde ergänzt.
Der Anhang “XÖV-Glossar” wurde aktualisiert.
Zukünftig wird anstelle der XÖV-Website "Spezifikations- und Produktionswerkzeuge" auf die Website "Gültige XÖV-Konfigurationen" verwiesen.

Release 2.1

Das Konformitätskriterium K-3 “Dokumentation” wurde um Vorgaben zur Angabe von Metadaten erweitert. In der neuen Namens- und Entwurfsregel NDR 32 “Dokumentation der Metadaten des Standards” werden die Vorgaben konkretisiert. Darüber hinaus wurden die Einleitung des Handbuchs um Aussagen zu Metadaten eines Standards erweitert und der Abschnitt “Metadaten eines XÖV-Standards” neu in das Kapitel “Spezifikation und Produktion von XÖV-Standards” aufgenommen. Der Unterabschnitt “Regelungen zur Bildung von Kennungen” des neuen Abschnitts ersetzt und verallgemeinert den früheren “Leitfaden zur Bildung von Uniform Resource Names” aus dem Kapitel “Bereitstellung und Nutzung von Codelisten”. (CR 667)
Der Abschnitt "Abbildung von Metadaten" im Kapitel "Bereitstellung und Nutzung von Codelisten" ist hinsichtlich der verfügbaren Metadatenelemente einer Codeliste und deren Abbildung in Genericode aktualisiert und erweitert worden. Die zugehörigen Beispiele zur Abbildung von Codelisten wurden dementsprechend aktualisiert. (CR 668)
Die Metadaten von Codelisten und die Inhalte von Codelisten (in der Code-Spalte und bis zu zwei Beschreibungsspalten) werden im XÖV-Fachmodell eines Standards zukünftig vollständig dokumentiert. Dementsprechend ändert sich die Methodik der Modellierung und Nutzung von Codelisten, sodass der Abschnitt "Nutzung von Codelisten" im Kapitel "Bereitstellung und Nutzung von Codelisten" diesbezüglich überarbeitet wurde. (CR 669)
Der Abschnitt "Nutzung weiterer Genericode-Funktionalitäten" wurde in das Kapitel "Bereitstellung und Nutzung von Codelisten" neu aufgenommen. Mit diesem Abschnitt wird explizit dargelegt, welche Elemente und Attribute des Genericode-Standards durch den XÖV-Standardisierungsrahmen und dessen Produkte nicht unterstützt werden. (CR 474)

Release 2.0.1

Die Übergangsfrist zur Gültigkeit der XÖV-Regelungen wurde auf 36 Monate erhöht. Hierzu wurde das Kapitel 3 “XÖV-Konformität” aktualisiert. (CR 526)
Für das XÖV-Konformitätskriterium K-5 “Nachhaltigkeit des Standards” wurden die Angaben zum Prüfinhalt um die für die Pflege zuständige Stelle erweitert. (CR 512)
In Abschnitt 8.3. “Abbildung von Codelisten” wurde die Tabelle 8.3. “Metadaten einer Codeliste” redaktionell überarbeitet. (CR 528)
Der Leitfaden zur Bildung von Uniform Resource Names (Abschnitt 8.4.1.) wurde überarbeitet. (CR 441)
Das XÖV-Glossar (Anhang B) wurde um den Begriff “XÖV-Starterpaket” erweitert. (CR 390)
In Abbildung 7.3. “Beziehungen zu den Eigenschaften einer XÖV-Kernkomponente” wurde der Stereotyp “xoevASBIE” an der Assoziation zwischen den Bausteinen “Anschrift” und “KodierungVerwaltungspolitisch” entfernt. (CR 479)
Der Abschnitt 2.5. “Änderungsmanagement” wurde um einen Verweis auf die XÖV-Webseite zur Übersicht der XÖV-Releases erweitert. (CR 529)
Darüber hinaus wurden redaktionelle Korrketuren vorgenommen. (CR 516)

Release 2.0

Die folgende Tabelle gibt einen Überblick über die vorgenommenen Änderungen:

XÖV-Handbuch 1.1

XÖV-Handbuch 2.0

Anmerkungen

Vorwort

neue Inhalte:

Zielgruppe und Zweck
Verwendete Standards

1. Einleitung

I.1 Einleitung

Neu verfasst (redaktionell)
Motivation und Nutzen
Ausrichtung auf Zielgruppen

I.2 Standardisierungsrahmen

Grundsätzliche Beschreibung des XÖV-Standardisierungsrahmens und Einführung der Begrifflichkeiten

2. XÖV-Konformitätskriterien

I.3 XÖV-Konformität

Redaktionelle Anpassungen

3. Produktion von XÖV-Standards

II.1 Spezifikation und Produktion von XÖV-Standards

Neu verfasst (redaktionell)

4. XÖV-UML-Profil

Kapitel entfällt

Dokumentation des XÖV-Profils erfolgt zukünftig auf der XÖV-Website

5. XÖV-Namens- und Entwurfsregeln

Bestandteil von II.1

NDR-23 entfallen, da sie inhaltlich Teil der NDR-28 ist

II.2 XÖV-Bibliothek

Die XÖV-Bibliothek ist eine neue Komponente und wird hier im Detail beschrieben
Weitere Informationen zur Bibliothek sind auf der XÖV-Website veröffentlicht

II.3 Nutzung von XÖV-Datentypen

Nutzung von XÖV-Datentypen explizit erläutert
Neu sind die Inhalte zur Nutzung der Datentypen anderer Standards und Normen (XÖV-Adapter)

6. Leitlinien zu Codelisten

II.5 Bereitstellung und Nutzung von Codelisten

Redaktionelle Anpassungen
Aktualisierte Begriffswelt
Leichterer Zugang zu den Inhalten
Dokumentation der praktischen Nutzung des XRepositorys erfolgt zukünftig auf den XÖV- und XRepository-Webseiten

7. Leitlinien zur Einbindung von XÖV-Kernkomponenten

II.4 Nutzung von XÖV-Kernkomponenten

Grundlegend neue Methodik zur Nutzung von Kernkomponenten

8. Beispielhafte Umsetzung eines XÖV-Standards

Kapitel entfällt

Der Beispielstandard XHamsterzucht wird nicht weiter gepflegt und dokumentiert
Ersatz wird durch das XÖV-Starterpaket und geplante online Tutorials geschaffen

9. XGenerator

Kapitel entfällt

Dokumentation zum XGenerator erfolgt zukünftig auf der XÖV-Website

A. Anhang zum Basisdatentyp String.Latin (keine Inhalte sondern Verweis auf xoev.de/latinchars/)

Kapitel entfällt

Anhang entfällt

Verweis auf String.Latin in “Verwendete Standards”

B. Überblick zu Velocity und OCL

Kapitel entfällt

Dokumentation des XÖV-Profils und seiner technischen Grundlagen erfolgt zukünftig auf der XÖV-Website

A Mitwirkende

C. XÖV-Glossar

B XÖV-Glossar

Grundlegende Überarbeitung der XÖV-Begriffswelt

D. Versionshistorie

C Versionshistorie

1. Mit der Entscheidung 2019/16 gibt der IT-Planungsrat den Standard DIN 91379 für die Verarbeitung von Namen vor.

2. Diese XMI-Version wird beispielsweise durch die aktuellen Long-Term Releases (LTR) des Modellierungswerkzeugs MagicDraw unterstützt sowie durch die aktuellen Versionen des Open-Source-Modellierungswerkzeugs Papyrus (getestet mit Version 2025-06 (4.36) / Release 7.1.0).

3. Das XÖV-Fachmodell muss für die prüfende Stelle in der Notation classic (XMI-Format und proprietäres Format des genutzten UML-Modellierungswerkzeugs) oder lite (Format XML) bereitgestellt werden

4. Die zertifizierende Stelle nutzt für XÖV-Fachmodelle in der Syntax classic das von der XÖV-Koordination empfohlene Long-Term-Release des Modellierungswerkzeugs MagicDraw oder eine aktuelle Version des Open-Source-Modellierungswerkzeugs Papyrus zur Verarbeitung des XÖV-Fachmodells. Weitere Editionen und Versionen der Modellierungswerkzeuge sind nach Absprache möglich.

5. Codelisten sind unabhängig von der Art ihrer Verwendung. Ein und dieselbe Codeliste kann entsprechend den jeweiligen Anforderungen unterschiedlich eingebunden werden.

6. siehe http://tools.ietf.org/html/rfc8141

7. Das für den Austausch verwendete Format basiert auf der Implementierung von Eclipse UML2.

Sofern nicht anders angegeben, stehen die Inhalte dieser Seite unter der Lizenz

Vorwort

Zielgruppe und Zweck

Ansprechpartner und Mitwirkende

Struktur des Dokuments

Teil I: Grundlagen

1. Einleitung

1.1. XÖV-Standards

1.2. XÖV-Standardisierungsrahmen

1.3. XÖV-Entwicklungsprozess

1.3.1. Entwurfsphase

1.3.2. Spezifikationsphase

1.3.3. Produktionsphase

2. XÖV-Produkte

2.1. XÖV-Regelungen

2.1.1. XÖV-Konformitätskriterien und Namens- und Entwurfsregeln

2.1.2. Good Practices

2.2. XÖV-Bausteine

2.2.1. XÖV-Datentypen und globale Eigenschaften(gruppen)

2.2.2. Etablierte Datenmodelle

Datenmodell-Syntaxen

XÖV-Angebot zu etablierten Datenmodellen

2.2.3. XÖV-Codelisten

2.3. Werkzeuge

2.3.1. XÖV-Produktionsumgebung

Inhalte für die classic Notation

Inhalte für die lite Notation

Prüfanweisungen

Übersetzungsanweisungen

2.3.2. XGenerator

2.4. Infrastruktur

2.4.1. XRepository

2.4.2. XÖV suite

2.4.3. XÖV-Bibliothek

2.4.4. XÖV-Dokumentationsplattform

2.5. Änderungsmanagement

3. XÖV-Konformität

3.1. XÖV-Konformitätskriterien

3.1.1. Bereitstellungspflichten

K-1 MUSS: Ein Standard der öffentlichen Verwaltung

K-2 MUSS: Freie Verwendung

K-3 MUSS: Dokumentation

K-4 MUSS: Veröffentlichung

K-5 MUSS: Nachhaltigkeit des Standards

3.1.2. Auskunftspflichten der entwickelnden und betreibenden Stellen

K-6 MUSS: Anzeige der Entwicklungsabsicht

K-7 MUSS: Informationen zum Status des Standards

3.1.3. Wiederverwendung der XÖV-Bausteine

K-16 SOLL: Nutzung der Bausteine der XÖV-Bibliothek

K-13 SOLL: Nutzung von Codelisten

3.1.4. Technische Kriterien

K-8 SOLL: Modellierung der Prozesse

K-9 MUSS: Modellierung der Datenstrukturen

K-10 MUSS: Einhaltung der XÖV-Namens- und Entwurfsregeln

K-14 MUSS: Erfolgreiche Verarbeitung des XÖV-Fachmodells durch die XÖV-Produktionsumgebung

K-15 SOLL: Nutzung einer sicheren Infrastruktur für den elektronischen Datenaustausch

3.2. XÖV-Zertifizierung

Teil II: Entwicklung eines XÖV-Standards

4. XÖV-Entwicklungsprozess

4.1. Entwurfsphase

4.2. Spezifikationsphase

4.3. Produktionsphase

4.3.1. XÖV-Produktionsumgebung

4.3.2. Verzeichnisstruktur in der XÖV-Produktionsumgebung

Verzeichnis bei XÖV-Notation lite

Verzeichnis bei XÖV-Notation classic

4.3.3. Ablauf des Produktionsprozesses

Produktionsprozess für lite

Produktionsprozess für classic

4.3.4. Erstellung eines Spezifikationsdokuments

5. Modellierung eines XÖV-Fachmodells

5.1. XÖV-Modellierungssprache und Notationen

5.2. XÖV-Fachmodell

5.2.1. Sprachelement XÖV-Fachmodell

5.2.2. Sprachelement Konfiguration

5.2.3. Sprachelement Metadaten

5.2.4. Sprachelement Externes Modell

5.2.5. Sprachelement Baustein

5.2.6. Sprachelement Codeliste

5.2.7. Sprachelemente Paket und Schemapaket

5.3. Regelungen zur Ausgestaltung des XÖV-Fachmodells

Inhalte für die `classic` Notation

Inhalte für die `lite` Notation

K-1 `MUSS`: Ein Standard der öffentlichen Verwaltung

K-2 `MUSS`: Freie Verwendung

K-3 `MUSS`: Dokumentation

K-4 `MUSS`: Veröffentlichung

K-5 `MUSS`: Nachhaltigkeit des Standards

K-6 `MUSS`: Anzeige der Entwicklungsabsicht

K-7 `MUSS`: Informationen zum Status des Standards

K-16 `SOLL`: Nutzung der Bausteine der XÖV-Bibliothek

K-13 `SOLL`: Nutzung von Codelisten

K-8 `SOLL`: Modellierung der Prozesse

K-9 `MUSS`: Modellierung der Datenstrukturen

K-10 `MUSS`: Einhaltung der XÖV-Namens- und Entwurfsregeln

K-14 `MUSS`: Erfolgreiche Verarbeitung des XÖV-Fachmodells durch die XÖV-Produktionsumgebung

K-15 `SOLL`: Nutzung einer sicheren Infrastruktur für den elektronischen Datenaustausch

Verzeichnis bei XÖV-Notation `lite`

Verzeichnis bei XÖV-Notation `classic`

Produktionsprozess für `lite`

Produktionsprozess für `classic`

5.2.1. Sprachelement `XÖV-Fachmodell`

5.2.2. Sprachelement `Konfiguration`

5.2.3. Sprachelement `Metadaten`

5.2.4. Sprachelement `Externes Modell`

5.2.5. Sprachelement `Baustein`

5.2.6. Sprachelement `Codeliste`

5.2.7. Sprachelemente `Paket` und `Schemapaket`

NDR-1 `MUSS`: Konsistente und vollständige Inhalte in XÖV-Fachmodell und den zentralen Bestandteilen des Standards

NDR-2 `MUSS`: Hauptstruktur eines XÖV-Fachmodells

NDR-3 `MUSS`: Nachrichten als globale Elemente

NDR-4 `SOLL`: Erlaubte Einbindungsarten für Codelisten

NDR-11 `SOLL`: Erlaubte Zeichen für Namen

NDR-13 `SOLL`: Versionsübergreifend eindeutige Nachrichtennamen

NDR-32 `MUSS`: Dokumentation der Metadaten des Standards

NDR-19 `SOLL`: Dokumentation in deutscher Sprache

NDR-33 `MUSS`: Codelisten konform zu den Regelungen des Codelisten-Handbuchs

NDR-22 `MUSS`: Konsistenz von Codelisten in XÖV-Fachmodell und XRepository (nur für XÖV classic)

NDR-24 `SOLL`: Nutzung der XÖV-Basisnachricht

NDR-28 `MUSS`: Valide W3C XSD-Schemas

NDR-29 `MUSS`: Identifizierende Namensräume

NDR-30 `MUSS`: Versionierung der XSD-Schemas

NDR-31 `SOLL`: Namensräume mit Versionen

9.4.1. XÖV-Baustein `Code`