Version:

4.0.0

Status:

Entwurf

Fassung:

2025-05-20

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

Das vorliegende Dokument ist eine Entwurfsfassung und NICHT zur operativen Nutzung vorgesehen.

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 KoSIT gibt 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-Handbuch 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 auf der Unified Modelling Language (UML) basierenden Methodik (im weiteren Verlauf als XÖV classic bezeichnet) steht nun eine XÖV-sprachlich und technisch leichtgewichtige Methodik mit XML-basierter Notation zur Verfügung (im weiteren Verlauf als XÖV lite bezeichnet). Alle bestehenden Regelungen des XÖV-Standardisierungsrahmens wie auch der Funktionsumfang der zugrundeliegenden Ansatzes und 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 zur 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. Es 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-Standardisierungsrahmen, 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 unterstützt, 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 KoSIT herausgegeben. Informationen rund um XÖV erhalten Sie über die XÖV-Website und die docs-Plattform der KoSIT. 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

Siehe Kapitel 1, .

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, vorhandene IT-Verfahren durch den Einsatz standardisierter Technologien und einheitlicher Verfahren zu vernetzen. Dazu stellt die XÖV-Koordination mit dem XÖV-Standardisierungsrahmen ein umfassendes methodisches und technisches Rahmenwerk für die Entwicklung sogenannter XÖV-Standard 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 lizenzkostenfreie Standards, die allen Interessierten frei zugänglich sind. 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 eigenen 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 der ersten Ergebnisse kann, muss jedoch nicht, durch ein spezifisches 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. Eine einheitliche Notation dieser Art erleichtert 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 zugehöriger 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 und eine Modellierungsumgebung 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-Fachmodell 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 XÖV-Entwicklungsprozess wird 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 verlustfreie 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.

Die XÖV-Notation lite wie auch die zugehörigen Modellierungsumgebungen unterstützen die UML-Notation derzeit nur im beschränkten Umfang. Mit den kommenden Releases der XÖV-Produkte soll eine umfassendere Unterstützung geboten werden.

2. XÖV-Produkte

Der XÖV-Standardisierungsrahmen ermöglicht die praktische Umsetzung der einzelnen Schritte des XÖV-Entwicklungsprozesses. Er besteht aus einer Reihe von aufeinander abgestimmten (XÖV-)Produkte, die in ihrer Gesamtheit den vollständigen Prozess der (Fort-)Entwicklung eines XÖV-Standards unterstützen beziehungsweise erst ermöglichen. Mit den folgenden Abschnitten wird zunächst eine Übersicht über die Produkte und ihrer zeitlichen Einordnung in den in Abschnitt 1.3, “XÖV-Entwicklungsprozess” dargestellten Prozess 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 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. Soll ein neuer Standard entwickelt werden, kann die über das XRepository bereitgestellte Interopmatrix genutzt werden, um sich über die mit dem Standardisierungsrahmen angebotenen XÖV-Bausteine und deren Verwendung in den jeweiligen XÖV-Standards zu informieren. So können bereits bestehende Lösungen in das eigene 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 solcher externer Lösungen sind die mit der XÖV-Bibliothek bereitgestellten XÖV-Bausteine für den Bereich Datenstrukturen (Datentypen und Kernkomponenten) und die auf dem XRepository bereitgestellten Bausteine aus dem Bereich Codelisten.

Die konkrete Spezifikation des XÖV-Fachmodells erfolgt mit den Mitteln der XÖV-Produktionsumgebung und dem darin enthaltenen XÖV-Profil für die Modelle in classic-Notation beziehungsweise dem zur lite-Notation gehörigen XSD-Schema. Beides ermöglicht die XÖV-spezifische Detaillierung des 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 docs-Plattform verfügbar. Hier finden Sie auch Informationen zu den Möglichkeiten sich an der Weiterentwicklung des XÖV-Standardisierungsrahmen 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 sogenannten Namens- und Entwurfsregeln (engl. Naming and Design Rules, kurz NDR). Während XÖV-Konformitätskriterien das grundsätzliche Vorgehen im XÖV-Entwicklungsprozess regeln, legen die XÖV-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-Standardisierungsrahmen sind in diesem Handbuch unter Kapitel 3, und Kapitel 6, vollständig dokumentiert.

2.1.2. Good Practise

Neben den Regelungen mit den Verbindlichkeitsstufen SOLL und MUSS existieren im Bereich der technischen Ausgestaltung auch sogenannten Good Practise. Sie dokumentieren in der Praxis bewährten Namens- und Entwurfsmustern und können helfen, den Entwicklungsaufwand zu reduzieren sowie die Einheitlichkeit und damit die Zugänglichkeit eines XÖV-Standards zu verbesser. 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 Fachmodell angewendet werden.

2.2. XÖV-Bausteine

Bausteine sind Datenstrukturen eines Standards, die mehrfach innerhalb des eigenen Standards, aber auch Standard-übergreifend verwendet werden können. Ergänzend dazu kann eine Standard auch die mit dem XÖV-Standardisierungsrahmen angebotenen sogenannten XÖV-Bausteine nutzen.

Die Wiederverwendung 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 Bausteine aus Sicht der XÖV-Koordination die Möglichkeit, die Vielfalt bestehender Lösungen zu harmonisieren. So steigert die gemeinsame 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 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 der Datentypen, Kernkomponenten 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 den jeweiligen Kapiteln des Handbuchs dargestellt.

2.2.1. XÖV-Datentypen

XÖV-Datentypen stellen fundamentale, meist fachunabhängig nutzbare Bausteine dar, deren Einsatz in unveränderter Form allen XÖV-Standards vorgesehen ist. Sie liegen als XML-Datentypen oder -Elemente vor und werden auf der Ebene von XSD-Schema in einen Standard eingebunden. Die Datentypen werden durch die XÖV-Bibliothek zur direkten Nutzung im XÖV-Fachmodell bereitgestellt. Die Bibliothek umfasst derzeit die im Folgenden aufgeführten XÖV-Datentypen:

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 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 Elemente anderer Standards und Normen: Neben den von der KoSIT betriebenen Bausteinen existieren in anderen Standards und Normen Bausteine, deren Wiederverwendung im XÖV-Kontext sinnvoll ist. Hierzu gehören beispielsweise die Bausteine zur Modellierung von Geodaten, die im GML-Standard des Open Geospatial Consortium (OGC) spezifiziert sind, und Bausteine zur Nutzung der vom World Wide Web Consortium (W3C) spezifizierten Inhalte des XML-Namensraums (u. a. das Attribut xml:lang). Die XÖV-Koordination stellt diese Bausteine in der XÖV-Bibliothek über so genannte XÖV-Adapter zur einheitlichen Nutzung bereit.

2.2.2. XÖV-Kernkomponenten

XÖV-Kernkomponenten sind fachübergreifende Datenstrukturen, die die Grundlage für die Ausprägung standardspezifischer Datenstrukturen darstellen können. Beispiele sind die Datenstrukturen zur Abbildung von Anschriften oder Namen natürlicher Personen.

Für die Nutzung von Kernkomponenten gelten weniger strikte Vorgaben als für die Nutzung von Datentypen, da fachbereichsübergreifende Vorgaben zum fachlichen Aufbau von Nachrichten wegen individueller rechtlicher Vorgaben häufig nicht umsetzbar wären.

Vielmehr soll die Bereitstellung der Kernkomponenten als Angebot verstanden werden, an dem sich die Vorhaben bei der Umsetzung ihrer spezifischen fachlichen Anforderungen orientieren können. Die Verwendung von Kernkomponenten hilft einem Standardisierungsvorhaben, eigene fachliche Ausgestaltungen für andere Vorhaben sichtbar und nachvollziehbar zu machen. Zudem helfen die Kernkomponenten und die zugrundeliegende Methodik bei der Gegenüberstellung eigener fachlicher Lösungen mit denen anderer XÖV-Standards, beispielsweise zur konzeptionellen Abstimmung auszutauschender Nachrichten zwischen (zukünftigen) Kommunikationspartnern. Auf der einen Seite können Verständnisprobleme und Fehler, die aufgrund unterschiedlicher Terminologien der verschiedenen Fachbereiche und -ressorts entstehen können, aufgelöst werden: Die Gemeinsamkeiten und damit auch die Interoperabilität der verschiedenen Standards können so unabhängig von den technischen Strukturen ihrer Bausteine betrachtet werden. Auf der anderen Seite können die gemeinsamen Erkenntnisse helfen, eine Harmonisierung auf semantischer, organisatorischer und rechtlicher Ebene anzustoßen.

Zur Visualisierung der fachlichen Anwendung der Kernkomponenten in den XÖV-Standards wird die Interopmatrix im XRepository bereitgestellt.

Die XÖV-Notation lite unterstützt die Methodik zur Auszeichnung der Verwendung von Kernkomponenten derzeit nicht. Mit den kommenden XÖV-Releases soll eine umfassende Unterstützung gewährleistet werden.

Alle XÖV-Kernkomponenten werden mit der XÖV-Bibliothek zur direkten Nutzung im XÖV-Fachmodell angeboten.

2.2.3. XÖV-Codelisten

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.

Ein Beispiel für eine Codeliste ist die Liste der Flughafencodes der International Air Transport Association (IATA). Sie beschreibt Verkehrsflughäfen weltweit durch die Vergabe eindeutiger Codes und zugehöriger Beschreibungen. Der Münchner Flughafen ist beispielsweise durch den Code MUC und die Beschreibung München / Franz Josef Strauß (englisch: Munic Airport) gegeben. Im Zusammenhang mit der Entwicklung von XÖV-Standards wird die Verwendung von Codelisten ausdrücklich empfohlen und gefördert.

Die Nutzung bereits bestehender Codelisten bietet Standardisierungsvorhaben unterschiedliche Vorteile. Die Wiederverwendung bestehender Codelisten reduziert den Aufwand bei der Erstellung und Abstimmung der Codelisten eines XÖV-Standards. Es werden zudem Aufwände vermieden, die sich durch Anpassung der in der Codeliste abgebildeten Sachverhalte ergeben. Beispielhaft seien hier die Codelisten zu administrativen Gebietseinheiten (Bundesländer, Regierungsbezirke, Regionen, Kreise, Gemeindeverbände und Gemeinden) genannt. Ständige Änderungen an diesen Gebieten erfordern die kontinuierliche Pflege der zugehörigen Codelisten. Diese Aufwände zur Pflege übernimmt in aller Regel der Herausgeber der jeweiligen Codeliste. Zudem erhöht die Verwendung gemeinsamer Codes und ihrer Semantik die Interoperabilität über die Grenzen des eigenen Standards hinweg. Dies kann die Aufwände bei der Implementierung des eigenen Standards in IT-Verfahren aber auch bei der Entwicklung von Schnittstellen zu anderen Standardisierungsbereichen reduzieren.

Zur Förderung der Wiederverwendung von Codelisten unterstützt die KoSIT die Herausgeber und Nutzer von Codelisten mit dem Handbuch zur Herausgabe und Nutzung von Codelisten (kurz Codelisten-Handbuch). Es behandelt das Konzept Codeliste im Detail und stellt ein einheitliches Vokabular und Regelwerk sowie methodische Anleitungen bereit. Im vorliegenden XÖV-Handbuch wird darüber hinaus in [ii:Codelisten] die konkrete Nutzung von Codelisten im XÖV-Fachmodell eines Standards erläutert.

Zum Codelisten-Handbuch konforme Codelisten sollen über die Infrastrukturkomponente XRepository zur standardübergreifenden Nutzung öffentlich bereitgestellt werden und können somit auf manuellem wie automatisierten Wege bezogen werden.

2.3. Werkzeuge

2.3.1. XÖV-Produktionsumgebung

Die XÖV-Produktionsumgebung ist die zentrale Komponente der XÖV-Spezifikations- und Produktionswerkzeuge. Sie beinhaltet zum einen alle zur Auszeichnung von XÖV-Fachmodellen in der classic-Notation erforderlichen Bestandteile wie zum Beispiel das XÖV-UML-Profil. Zum anderen ist die XÖV-Produktionsumgebung eine Anwendung des XGenerators, mittels derer die automatisierte Prüfung des XÖV-Fachmodells und die Generierung der Bestandteile eines XÖV-Standards des Standards aus dem XÖV-Fachmodell erfolgt.

Weitere Informationen zum Produkt sind über die docs-Plattform unter XÖV-Produktionsumgebung bereitgestellt.

2.3.2. XÖV-Profil

Das XÖV-Profil besteht aus drei Bestandteilen, die zur Spezifikation, Generierung und Prüfung eines XÖV-Fachmodells genutzt werden.

Zur Spezifikation eines Standards werden Mittel für die technische Konkretisierung der Inhalte eines Fachmodells bereitgestellt (XÖV-Stereotyp und XSD-Schema-Datentypen).

Für die Generierung der Bestandteile eines XÖV-Standards stehen über das Profil Anweisungen zur Verfügung, die durch das Werkzeug XGenerator genutzt werden (XÖV-Übersetzungsanweisungen).

Die mit dem Profil bereitgestellten Prüfanweisungen ermöglichen sowohl den Standardisierungsvorhaben als auch der Zertifizierungsstelle eine Reihe von XÖV-Regelungen mittels XGenerator zu prüfen (XÖV-Prüfanweisungen).

Weitere Informationen zum Produkt sind über die docs-Plattform unter XÖV-Profil bereitgestellt.

2.3.3. 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 Anweisungen zur Produktion 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 (XMI-Format) oder lite-Notation (XML). Eine XMI-Darstellung des XÖV-Fachmodells in 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 die docs-Plattform unter XGenerator bereitgestellt.

2.4. Infrastruktur

2.4.1. XRepository

Das XRepository ist die zentrale XÖV-Distributionsplattform. 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 manuell sowie automatisiert (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 KoSIT ein wichtiges Werkzeug für die tägliche Arbeit.

Ein wichtiger Bestandteil des XRepository ist die Interopmatrix. Sie hilft Standardisierungsvorhaben, sich eine Übersicht über die von der XÖV-Koordination herausgegebenen Kernkomponenten und deren Nutzung durch die XÖV-Vorhaben zu verschaffen. Die interaktive Visualisierung ermöglicht den Vorhaben einen effizienten und umfassenden Zugang zu bestehenden Informationen in diesem Bereich.

Hierzu gehören auf der einen Seite Übersichten zu den Kernkomponenten, deren Strukturen und Dokumentation, sowie die Häufigkeit ihrer Verwendung in XÖV-Standards, auf der anderen Seite detaillierte Informationen, welche die semantische und strukturelle Beziehung der Bausteine eines Standards zu den Kernkomponenten sowie der Bausteine untereinander darstellen. Unterschiede und Gemeinsamkeiten von Standards können so auf einfache Weise untersucht werden.

Die Interopmatrix erlaubt damit einen direkten Einblick in die fachlichen Konzepte anderer Standards, wie beispielsweise zukünftiger Kommunikationspartner, und kann einem XÖV-Vorhaben beim Entwurf des eigenen Fachmodells als Orientierung dienen. Darüber hinaus unterstützt sie bei der konzeptionellen Abstimmung der auszutauschenden Daten, bei der Entwicklung gemeinsamer Begrifflichkeiten und bei der Harmonisierung organisatorischer und rechtlicher Rahmenbedingungen.

Weitere Informationen zum Produkt sind über die docs-Plattform unter XRepository bereitgestellt.

2.4.2. XÖV-Bibliothek

Die XÖV-Bibliothek stellt für Standardisierungsvorhaben den zentralen Bezugspunkt für XÖV-Datentypen und -Kernkomponenten dar. Sie 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 XÖV-Fachmodells, welches in andere Standards direkt eingebunden wird und damit die Bausteine direkt verfügbar macht. Die XÖV-Bibliothek wird von der KoSIT in den Formaten der classic-Notation (MagicDraw und Papyrus) sowie der lite-Notation (XML) bereitgestellt.

Weitere Informationen zum Produkt sind über die docs-Plattform unter XÖV-Bibliothek bereitgestellt.

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-Standardisierungsrahmen, wie beispielsweise der XGenerator, die XÖV-Kernkomponenten oder das XÖV-Handbuch. Alle Produkte sind auf der docs-Plattform 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 der docs-Plattform 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.

Sollte Ihr Änderungswunsch kein spezielles XÖV-Produkt betreffen, 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 und 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. Die Einhaltung dieser technischen Regelungen wird durch die Konformitätskriterien sichergestellt.

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 es 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 der docs-Plattform 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 der entwickelnden und betreibenden Stellen,
Wiederverwendung der XÖV-Bausteine, 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 Tabelle 2, “Übersicht der XÖV-Konformitätskriterien” dargestellten Konformitätskriterien bilden die Grundlage der 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 der XÖV-Bausteine
K-11	`SOLL`	Nutzung der XÖV-Kernkomponenten
K-12	`SOLL`	Nutzung der XÖV-Datentypen
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 Informationen bereitstellen, die erforderlich sind, 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-Schemata und eines dazu konsistenten Spezifikationsdokuments. Die Regelungen zur Abbildung der Metadaten eines XÖV-Standards sind in Abschnitt 6.3.1, “NDR-32 (MUSS): Dokumentation der Metadaten des Standards” 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-Schemata und Spezifikationsdokument des Standards liegen vollständig und konsistent vor

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

K-4 `MUSS`: Veröffentlichung

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

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

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

Prüfinhalt: Existenz von XSD-Schemata, 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 für die Pflege zuständigen 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-11 `SOLL`: Nutzung der XÖV-Kernkomponenten

Die Beziehungen der fachlichen Bausteine eines XÖV-Standards zu den durch die XÖV-Koordination in der XÖV-Bibliothek veröffentlichten XÖV-Kernkomponenten sollen identifiziert und ausgezeichnet werden. Hierfür ist die in Kapitel 11, beschriebene Methodik anzuwenden.

Begründung: Die Auszeichnung der Beziehungen ermöglicht der XÖV-Koordination die Auswertung der Gemeinsamkeiten und Unterschiede zwischen den Bausteinen von Standards und den XÖV-Kernkomponenten, sowie deren fachliche Motivation. Die Ergebnisse der Auswertung werden über die im XRepository verfügbare Interopmatrix für alle XÖV-Vorhaben bereitgestellt. Die Interopmatrix macht die Bausteine eines Standards und seine fachliche Ausgestaltung sichtbar und mit den Bausteinen anderer Standards vergleichbar und fördert so sowohl die Wiederverwendung als auch die Harmonisierung der bereitgestellten XÖV-Kernkomponenten.

Prüfgrundlage: Im XRepository bereitgestelltes XÖV-Fachmodell^[3]; Begründung eventuell unvollständiger Auszeichnung

Prüfinhalt: Fachspezifische Bausteine (Datenstrukturen) des Standards hinsichtlich ihrer Beziehungen zu XÖV-Kernkomponenten; Begründung eventuell unvollständiger Auszeichnung

Die Methodik zur Auszeichnung wird erst mit dem kommenden Release der XÖV lite Notation bereitgestellt. Das Konformitätskriterium K-11 wird aus diesem Grunde für XÖV-Standards in der lite-Notation bis zu diesem Zeitpunkt ausser Kraft gesetzt werden und somit nicht zertifizierungsrelevant sein.

K-12 `SOLL`: Nutzung der XÖV-Datentypen

Bei fachlicher Eignung sollen XÖV-Standards die mit der XÖV-Bibliothek herausgegebenen XÖV-Datentypen anstelle eigener Datentypen verwenden. Hierzu ist die in Kapitel 10, dargelegte Methodik anzuwenden.

Datentypen anderer XML-Fachstandards und Normen dürfen in XÖV-Standards genutzt werden. Falls für sie in der XÖV-Bibliothek ein XÖV-Adapter zur Verfügung steht, soll eine Nutzung über den entsprechenden Adapter erfolgen.

Begründung: Die Verwendung einheitlicher XÖV-Datentypen verbessert die Interoperabilität und erleichtert die Implementierung. Die einheitliche Wiederverwendung existierender Bausteine anderer Standards und Normen wird durch die Bereitstellung von XÖV-Adaptern gefördert.

Prüfgrundlage: Im XRepository bereitgestelltes XÖV-Fachmodell^[3]; Begründung eventueller Abweichungen

Prüfinhalt: Datentypen 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 [ii: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]; Begründung eventueller Abweichungen

Prüfinhalt: Datenstrukturen hinsichtlich der verwendeten Codelisten; 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. 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; Begründung eventueller Abweichungen

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 XÖV classic oder XÖV 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. Das XÖV-Fachmodell ist Grundlage für die XÖV-Konformitätsprüfung.

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

Prüfinhalt: Fehlerfreie Verarbeitung des XÖV-Fachmodell^[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 grundleger 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 Schema(ta) durch Einsatz 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 herausgegebenen XÖV-Produktionsumgebung in der 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-Schemata.

Begründung: Die Qualitätsziele des XÖV-Standardisierungsrahmen 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; Begründung eventueller Abweichungen

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. Prüfung der XÖV-Konformität

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-Schemata 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 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 der docs-Plattform 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-Standard. 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, ein XÖV-Fachmodell von Grund auf neu entwickeln oder ein bestehendes fortzuschreiben.

In den folgenden Abschnitten werden die Schritte beschrieben, die sowohl Neuvorhaben als auch Bestandsvorhaben zur Entwicklung eines 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-Spezifikations- und Produktionswerkzeuge als auch die einzelnen Schritte zur Erstellung der Bestandteile eines XÖV-Standards eines XÖV-Standard dargestellt.

4.1. Entwurfsphase

Die Entwurfsphase ist geprägt durch den kollaborativen Prozess der Erhebung von Informationen zu den Datenübermittlungsszenarien und den administrativen Informationen 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.

Administrativen Informationen wie beispielsweise der Name, die Kennung oder die Beschreibung eines Standards werden im Kontext des XÖV-Standardisierungsrahmens als Metadaten bezeichnet. Sie werden später 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 Kapitel 8, .

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 ebenfalls die rechtlichen, organisatorischen, semantischen und technischen Rahmenbedingungen von den am Vorhaben Beteiligten erarbeitet, aufgeklärt 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 einheitliche 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 Form der ü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 und sollte, wird insbesondere durch die Wahl der XÖV-Notation (lite/classic) 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 n 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 konkretisiert und hinsichtlich ihrer technischen Umsetzung in die Bestandteile eines XÖV-Standards im Detail ausgestaltet. Der Prozess der technischen Ausgestaltung geht in der Regel mit der Modellierung beispielsweise einer Nachrichten des Standards im XÖV-Fachmodell einher.

Modellierung: Erhobene Informationen werden formal, eindeutig und durch die Spezifikation- und Produktionswerkzeuge 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 ein Codelisten-Fachmodell eines Standards abgebildet. Grundlage der Modellierung eines XÖV-Fachmodells ist die XÖV-Modellierungssprache und eine oder mehrere zugehörige 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 [g:produktionsphase] aus dem XÖV-Fachmodell erzeugten technischen technische Bestandteile des Spezifikationsdokuments werden um manuell erstellte Teildokumente mit zusätzlichen Informationen ergänzt. Neben dem obligatorischen Spezifikationsdokument werden weitere Dokumente zum Standard (z. B. [g:betriebskonzept]) oder seinen Versionen 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 technische 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 nach Abschluss der Modellierung und währenddessen zur Kontrolle der Qualität von Zwischenergebnissen statt.

Die Produktion wird konkret mit den XÖV-Spezifikations- und Produktionswerkzeugen, d. h. in der XÖV-Produktionsumgebung und durch den XGenerator ausgeführt. Die XÖV-Produktionsumgebung 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 mittels Werkzeugen der XÖV-Produktionsumgebung in ein Spezifikationsdokument überführt werden.

4.3.1. XÖV-Produktionsumgebung

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

Die Inhalte der XÖV-Produktionsumgebung 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 Inhalte Übersetzungsanweisungen dar, die eine automatisierte Erstellung der Bestandteile eines XÖV-Standards ermöglichen, 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. Darüber hinaus stehen Übersetzungsanweisungen für die Generierung der zentralen teschnischen Bestandteile des Spezifikationsdokuments zur Verfügung.

Neben den Inhalten für den XGenerator existieren Inhalte und Werkzeuge für die Prüfung der technischen Bestandteile des Spezifikationsdokuments und ihre Übersetzung in ein Spezifikationsdokument.

Die XÖV-Produktionsumgebung wird für jede XÖV-seitig unterstützte Modellierungsumgebung in einer konkreten Ausprägung angeboten:

XÖV classic für MagicDraw
XÖV classic für Papyrus
XÖV lite

Für Neuvorhaben wird die aktuelle XÖV-Produktionsumgebung in einem XÖV-Starterpaket bereitgestellt.

4.3.2. Verzeichnisstruktur in der XÖV-Produktionsumgebung

Die Spezifikation eines Standards erfolgt in der XÖV-Produktionsumgebung. Die Umgebung gibt je Ausprägung (XÖV classic oder XÖV lite) eine bestimmte Verzeichnisstruktur vor, die ein passendes Zusammenspiel der Modellierungs-, Spezifikations- und Produktionswerkzeuge erlaubt. In der XÖV lite Ausprägung ist die Verzeichnisstruktur, in dem ein Standard spezifiziert und produziert wird, wie in der folgenden Abbildung dargestellt aufgebaut.

Verzeichnisstruktur eines XÖV-Standards

└───xbeispiel
    │   generate_documentation.bat
    │   XBeispiel.xgen-project
    │
    ├───build
    │   ├───docbook
    │   ├───lite-model
    │   ├───plantuml
    │   ├───schematron
    │   ├───wsdl
    │   └───xsd
    |
    ├───codelists
    |
    ├───docbookzubehoer
    |
    ├───model
    │   │   xbeispiel_2.0.1.xml
    │   │
    │   └───externeModelle
    │           xoev-bibliothek_2022-12-15.xml
    │
    ├───src
    │   │   spezifikation.xml
    │   │
    │   ├───docbook
    │   ├───media
    │   └───plantuml
    |
    └───xgen-applications
        ├───xoev-lite
        └───xoev-profil

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 Skript zur beispielhaften Überführung der technischen Bestandteile des Spezifikationsdokuments der PDF-Generierung
build (Verzeichnis): Das Verzeichnis wird automatisch vom XGenerator erstellt. Es enthält das Ergebnis der Prüfung und Übersetzung des XÖV-Fachmodells.
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 Codelisten 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 dem DocBook-Gesamtdokument.
model (Verzeichnis): Das Verzeichnis enthält das eigene XÖV-Fachmodell in der XÖV lite Notation und die genutzten externen Modelle in einem oder mehreren Unterverzeichnissen.
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-Produktionsumgebung bereitgestellten Anwendungen gehören.

In der XÖV 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 und Übersetzung des XÖV-Fachmodells.
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 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 XÖV classic Notation, d. h. im Format des genutzten UML-Modellierungswerkzeugs, sowie die externen Modelle zusätzlich in der XÖV lite Notation. Darüber hinaus enthält des Verzeichnis die mit der XÖV-Produktionsumgengung gelieferten UML-Profile und -Modelle, welche die Modellierung eines XÖV-Fachmodells in der XÖV 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-Produktionsumgebung bereitgestellten Anwendungen mit dem Namen "xoev-lite" und "xoev-profil" gehören.
\*.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

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 XÖV lite und XÖV classic Notation unterschieden.

Bei einem XÖV-Fachmodell in der XÖV 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).

Bei einem XÖV-Fachmodell in der XÖV 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 XÖV 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-Hanbuchs ü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 von XGenerator erzeugten Bestandteile des Standards (insb. die XSD-Schemas) keiner weiteren Bearbeitung bedü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- oder AsciiDoc-Format ist weit verbreitet und wird durch eine Reihe frei verfügbarer Werkzeuge unterstützt. Die XÖV-Produktionsumgebung 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 die 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 genutzten Sprachelemente der XÖV-Modellierungssprache und zugehöriger beispielhafter Umsetzungen in den Notationen XÖV lite und XÖV classic erläutert.

5.1. XÖV-Modellierungssprache und Notationen

Die XÖV-Modellierungssprache wird zur Spezifikation eines XÖV-Fachmodells genutzt und betrifft alle durch die 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 Symbole in einem XÖV-Fachmodell kombiniert werden können.

Die letztendliche Umsetzung dieser zunächst abstrakten Sprachelemente und Regeln erfolgt mittels XÖV-Notationen. Sie definieren die konkreten grafischen oder textuellen Symbole zur Abbildung von Informationen beispielsweise zu den Metadaten eines Standards in ein XÖV-Fachmodell.

XÖV bietet mit XÖV classic und XÖV lite zwei alternative, gleichwertige Notationen der XÖV-Modellierungssprache an. Beide Notationen setzen gleichermassen 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 verarbeitet. Beispiel 1, “Datentyp in XÖV-Notationen” zeigt beispielhaft die Spezifikation eines Datentyps in XÖV lite und XÖV classic.

Beispiel 1. Datentyp in XÖV-Notationen

XÖV classic

XÖV lite

classic

lite

Die Unterschiede der Notationen liegen insbesondere in der zu nutzenden Repräsentationsform (UML oder XML) und in den sich daraus ergebenden, möglichen Modellierungswerkzeugen und resultierenden Modellierungsumgebungen.

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 Modellierungsumgebung beantwortet werden, in der die Entwicklung, Fortschreibung 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 die 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 unten stehenden Abbildung in der Übersicht dargestellt.

Abbildung 2. Sprachelemente im Überblick

5.2.1. Sprachelement `Konfiguration`

Im Bereich der Konfiguration eines XÖV-Fachmodells können grundlegende technische Konfigurationen zum Standards und seiner Abbildung in XML-Schema vorgenommen werden. Dies können beispielsweise der XML-Namensraum (namespace) und ein zugehöriges XML-Präfix (prefix) des Standards sein. Für fast alle globalen Einstellungen gilt, dass sie bei Bedarf auf konkreter Ebene angegeben werden können. 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 Produktion der XSD-Schemas wird in diesem Fall die Konfiguration des Schemapakets anstelle einer globalen Konfiguration genutzt.

Tabelle 3. Umsetzung der Sprachelemente zu `Konfiguration`
`XÖV classic`	UML-Stereotyp `xsdModel`
`XÖV lite`	XML-Element `konfiguration.xoev-fachmodell`

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 in in Anhang A, dargestellt.

5.2.2. 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 3, “Sprachelemente zu sind die Sprachelemente zur Spezifikation der Metadaten eines Standards und seiner Version sowie ihre Angabehäufigkeit im Überblick dargestellt.

Abbildung 3. 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`
`XÖV classic`	Stereotypen `xoevStandard` und `xoevVersionStandard`
`XÖV lite`	XML-Elemente `metadaten.standard` und `metadaten.versionStandard`

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

Beispiel 2. Metadaten am Beispiel des Standards XBau (XÖV 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>
      <versionXOEVProduktionsumgebung>1.0.0</versionXOEVProduktionsumgebung>
      <versionXOEVHandbuch>3.0.1</versionXOEVHandbuch>
      <nameModellierungswerkzeug>MagicDraw</nameModellierungswerkzeug>
      <versionModellierungswerkzeug>19.0</versionModellierungswerkzeug>
   </metadaten.versionStandard>

In Kapitel 8, 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.3. Sprachelement `Externe Inhalte`

Neben den eigenen Inhalten eines Standards sind in einem XÖV-Fachmodell in der Regel auch externe Inhalte integriert um diese im eigenen Standard nutzen zu können. So werden beispielsweise die von der XÖV-Koordination angebotenen XÖV-Bausteine (Datentypen und Kernkomponenten) genutzt, indem die XÖV-Bibliothek als externes Modell in das eigene XÖV-Fachmodell eingebunden wird. Die Einbindung externer Inhalte bietet 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 Basis-Modul zu kapseln und dieses in einer Reihe von Fachmodulen wieder einzubinden.

5.2.4. Sprachelement `Bausteine`

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

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. Es besteht aber auch die Möglichkeit, dass Bausteine aus anderen XÖV-Fachmodellen im eigenen Standard genutzt werden.

Ein Sonderfall sind in diesem Zusammenhang die sogenannten XÖV-Bausteine, die durch die XÖV-Koordination kuratiert mit der XÖV-Bibliothek zur Nutzung bereitgestellt werden.

Die mit dem XÖV-Standardisierungsrahmen angeboten Bausteine werden XÖV-Bausteine genannt. XÖV-Bausteine werden in der XÖV-Bibliothek zusammengefasst 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 4, “Sprachelemente zu gibt einen Überblick über die Sprachelemente der XÖV-Modellierungssprache, die zur Spezifikation von Bausteinen genutzt werden können.

Abbildung 4. Sprachelemente zu Bausteine

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

Tabelle 5. Umsetzung der Sprachelemente zu `Baustein`
Nachricht
	Klasse mit Stereotyp `xsdMessage` annotiert
	Element `nachricht`
Datentyp (einfacher und komplexer)
	Klasse mit Stereotyp `xsdNamedType` annotiert
	Element `datentyp` ohne Kindeigenschaften
	Klasse mit Stereotyp `xsdNamedType` annotiert
	Element `datentyp` mit Kindeigenschaften
Code-Datentyp
	implizite Modellierung (Klasse mit Stereotyp `xsdNamedType` annotiert und mit Nutzungsbeziehungen zu einer Klasse mit dem Stereotyp `xoevCodeliste` oder `xoevVersionCodeliste`)
	Element `codeDatentyp`
Globale Eigenschaft (Element und Attribut)
	Klasse mit Stereotyp `xsdElement` annotiert
	Element `globaleEigenschaft`
	Klasse mit Stereotyp `xsdAttribute` annotiert
	Element `globaleEigenschaft` mit dem Attributwert `xsdAttribute=true`
Globale Eigenschaftsgruppe (Elemente und Attribute)
	Klasse mit Stereotyp `xsdGroup` annotiert und mit XML-Attributen
	Element `globaleEigenschaftsgruppe` mit dem Attributwert `xsdAttribute=true`
	Klasse mit Stereotyp `xsdGroup` annotiert und mit XML-Elementen
	Element `globaleEigenschaftsgruppe` mit dem Attributwert `xsdAttribute=true`

Eine detailliertere Darstellung der Sprachelemente zur Spezifikation von Bausteinen ist in den Abschnitten zum jeweiligen Bausteintyp gegeben.

5.2.5. Sprachelement `Codeliste`

Die Codeliste ist eine spezifische Art eines Bausteins. Anders als die Bausteine, die sich mit den in Abbildung 4, “Sprachelemente zu dargestellten Sprachelementen spezifizieren lassen, handelt es sich bei Codelisten nicht um Datenstrukturen sondern um Listen.

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.

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

Eine vereinfachte Übersicht der Sprachelemente des XÖV-Standardisierungsrahmen zur Spezifikation von Codelisten ist in der untenstehenden Abbildung gegeben.

Abbildung 5. Sprachelemente zu Codeliste

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

5.2.6. Sprachelemente `Paket` und `Schemapaket`

Die Strukturierung des XÖV-Fachmodells hilft dem Menschen, den Überblick zu behalten, fremde von eigenen Inhalten klar zu trennen und die eigenen Inhalte nach unterschiedlichen Kriterien (z. B. fachlich, technisch und/oder organisatorisch) zu ordnen. 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 lite und classic dar.

Beispiel 3. Strukturen von XÖV-Fachmodellen

XÖV classic

XÖV 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. Mit dem Sprachelement Paket ist eine allgemeine Strukturierung eines XÖV-Fachmodells möglich.

Die UML-basierte Notation XÖV classic ermöglicht die Strukturierung eines XÖV-Fachmodells direkt über die Anlage und Verschachtelung von UML-Paketen im Paketbaum des Modellierungswerkzeugs. 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) ausgezeichnet werden.

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

Abbildung 6, “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 6. Sprachelemente zu Paket und Schemapaket

In Tabelle 6, “Umsetzung der Sprachelemente zu wird eine Übersicht der relevantesten Sprachelemente zur Strukturierung von Informationen im XÖV-Fachmodell und ihrer Umsetzung in den XÖV-Notationen dargestellt.

Tabelle 6. Umsetzung der Sprachelemente zu `Paket` und `Schemapaket`
`XÖV classic`	UML-Paket und UML-Paket mit Stereotyp `xsdSchema`
`XÖV lite`	XML-Elemente `paket` und `xsdSchema`

Tabelle 7. Sprachelemente zur Strukturierung von XÖV-Fachmodell
Strukturelement	Modellierung
Modellwurzel	Oberstes Paket
Modellwurzel	Element `xoev-fachmodell`
eigene Inhalte (ausser Codelisten)	Paket direkt unterhalb der Modellwurzel mit dem Stereotyp `xoevStandard` (kurz Modellpaket)
eigene Inhalte (ausser Codelisten)	alle Pakete und Inhalte unter der Modellwurzel, die nicht mit dem Element `externesModell` modelliert wurden
Metadaten des Standards und seiner Version	werden am Modellpaket mittels der Stereotypen `xoevStandard` und `xoevVersionStandard` angegeben
Metadaten des Standards und seiner Version	werden mit den Elementen `metadaten.standard` und `metadaten.versionStandard` angegeben
genutzte externe Modelle	Modellpakete unterhalb des Pakets mit dem Namen `Externe Modelle`, das direkt unterhalb der Modellwurzel liegt
genutzte externe Modelle	Inhalte, die mit dem Element `externesModell` modelliert wurden
genutzte Codelisten	Pakete unterhalb des Pakets mit dem Namen `Codelisten`, das direkt unterhalb der Modellwurzel liegt
genutzte Codelisten	Codelisten sind keine Bestandteile eines lite-Modells
eigene Codeliste	Paket unterhalb des `Codelisten`-Pakets mit dem Namen `eigene Codelisten`
eigene Codeliste	Codelisten sind keine Bestandteile eines lite-Modells
externe Codelisten	Paket unterhalb des `Codelisten`-Pakets mit dem Namen `externe Codelisten`
externe Codelisten	Codelisten sind keine Bestandteile eines lite-Modells
eigene(s) Schemapaket(e)	ein mit dem Stereotyp `xsdSchema` ausgezeichnetes Paket direkt oder indirekt unterhalb des Modellpakets
eigene(s) Schemapaket(e)	ein unterhalb des Elements `xsdSchema` modellierter Inhalt

5.3. Regelungen zur Ausgestaltung des XÖV-Fachmodells

Die technische Ausgestaltung eines XÖV-Standards unterliegt XÖV-spezifischen Namens- und Entwurfsregeln, welche sowohl die Einheitlichkeit als auch die technische und syntaktische Interoperabilität von XÖV-Standards fördern sollen.

Ergänzend dazu werden im XÖV-Handbuch mit den sogenannten XÖV Good Practise eine Reihe von Umsetzungshinweisen gegeben, die nicht zertifizierungsrelevant sind, aber als gute Beispiele aus der Praxis zur Orientierung genutzt werden können.

Eine detaillierte Übersicht der XÖV-Namens- und Entwurfsregeln ist in Kapitel 6, gegeben.

6. XÖV-Namens- und Entwurfsregeln

Mit dem in Abschnitt 3.1.4.3, “K-10 beschriebenen Konformitätkriterium wir die Einhaltung der XÖV-Namens- und Entwurfsregeln (kurz NDR) gefordert. Die NDRs regeln 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 MUSS- und SOLL-Regeln sicher. Grundlage hierfür ist eine zur verwendeten Handbuchversion gültige Konfiguration der genutzten XÖV-Produkte. Alle gültigen Konfigurationen sind auf der docs-Plattform 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 Inhalte in XÖV-Fachmodell und technischen 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	Unveränderte Übernahme von XÖV-Codelisten
NDR-24	SOLL	Wiederverwendung generischer Nachrichteneigenschaften
XML Schema-Konformität
NDR-28	MUSS	Valide W3C XSD-Schemata
Namensräume und Versionen
NDR-29	MUSS	Identifizierende Namensräume
NDR-30	MUSS	Versionierung der XSD-Schemata
NDR-31	SOLL	Namensräume mit Versionen

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

6.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.

6.1.1. NDR-1 (MUSS): Konsistente Inhalte in XÖV-Fachmodell und technischen Bestandteilen des Standards

Die Inhalte der erzeugten XSD-Schemata müssen den korrespondierenden Inhalten des XÖV-Fachmodells genau entsprechen.

Erläuterung: Die XSD-Schemata eines XÖV-Standards müssen zur Einhaltung der XÖV-Konformität mit dem durch die XÖV-Koordination bereitgestellten XGenerator und die XÖV-Produktionsumgebung, in einer aktuell gültigen Konfiguration produziert werden. Die XÖV-Übersetzungsanweisungen der XÖV-Produktionsumgebung gewährleisten eine eindeutige und korrekte Übersetzung der Inhalte des XÖV-Fachmodells nach XSD-Schema. Automatisiert erstellte XSD-Schemata dürfen nachträglich nicht manuell verändert werden.

Begründung: Eine einheitliche Übersetzung eines XÖV-Fachmodells in XSD-Schema 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 XML Schema schließen lassen.

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

6.1.2. 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 teilt auf obersten Ebene genutzte fremde und eigene Inhalte.

Tabelle 9. NDR-2: Hauptstruktur eines XÖV-Fachmodells
classic	lite
Inhalte des Standards
Im classic-Modell eines XÖV-Standards muss es genau ein UML-Paket geben, dass mit dem Stereotyp `xsdXModel` ausgezeichnet ist. Alle Inhalte die zur Erzeugung der XSD-Schemata des Standards herangezogen werden, müssen sich unterhalb dieser Paketstruktur befinden.	Anders als in der 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
Im classic-Modell eines XÖV-Standards muss es genau ein UML-Paket mit dem Namen `Externe Modelle` geben. Unterhalb dieser Paketstruktur müssen die im eigenen Standard genutzten Modelle anderer Standards und der XÖV-Bibliothek abgelegt werden.	Die Einbindung externer Modelle zur Nachnutzung im eigenen XÖV-Standard erfolgt mittels XML-Element `externesModell`. Die so eingebundenen Modelle müssen im Dateisystem am selben Ort wie die Modelldatei des nutzenden Standards liegen.
Beispiele

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

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

6.1.3. 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 (Stereotyp xsdMessage, Elementname nachricht) zur Modellierung von Nachrichten erfolgt die Umsetzung automatisiert.

Begründung: Im Kontext eines XÖV-Standards elektronisch übermittelte Nachrichten stellen 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 XML Schema-Definitionen 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.

6.1.4. NDR-4 (SOLL): Erlaubte Einbindungsarten für Codelisten

Eine Codeliste soll ausschließlich mittels der in Nutzung von Codelisten beschriebenen Code-Typen 1 bis 4 in einem XÖV-Standard genutzt werden.

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.

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

6.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.

6.2.1. NDR-11 (SOLL): Erlaubte Zeichen für Namen

Namen von XML-Attributen, XML-Elementen und XML-Typen eines XÖV-Standards sollen nur Buchstaben, Ziffern, Punkte, Unterstriche und Bindestriche enthalten.

Erläuterung: Namen von XML-Attributen (Stereotyp xsdAttribute), XML-Elementen (Stereotyp xsdElement oder xsdGlobalElement) und XML-Typen (Stereotyp xsdNamedType), die innerhalb einer XML Schema-Definition (Stereotyp xsdSchema) definiert sind, sollen nur die im Folgenden aufgeführten Zeichen beinhalten:

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.

6.2.2. 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.

Erläuterung: Diese Regel bezieht sich auf Nachrichten (Stereotyp xsdMessage).

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.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.

6.3.1. 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 sind, wie in Metadaten eines XÖV-Standards geregelt, mittels der Stereotypen xoevStandard und xoevVersionStandard des XÖV-Profils im XÖV-Fachmodell 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-Zertifzierungsstelle) 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.

6.3.2. NDR-19 (SOLL): Dokumentation in deutscher Sprache

Es sollen alle Bestandteile eines XÖV-Standards in deutscher Sprache dokumentiert 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.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.

6.4.1. 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 (www.xoev.de/de/codelistenhandbuch). Bitte entnehmen Sie die zu diesem XÖV-Handbuch gültige(n) Version(en) des Codelisten-Handbuchs der auf unserer Website veröffentlichten Tabelle Gültige XÖV-Konfigurationen.

Wird ein Standard in einer neuen Version herausgegeben, können bereits bestehende Codelistenversionen in unveränderter Form weiter verwendet 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 Mindesmaß an Konsistenz und Vollständigkeit im Bereich ihrer Daten, Metadaten und Strukturen sichergestellt, die eine standardübergreifend einheitliche Nutzung und Modellierung 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 XÖV-Spezifikations- und -Produktionswerkzeuge 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 durch die Nutzung von Codelisten aus dem XRepository sowie die Nutzung der XÖV-Spezifikations- und Produktionswerkzeuge in der von der XÖV-Koordination vorgegebenen Version sichergestellt, wenn sie unterhalb des Pakets "Codelisten/eigene Codelisten" im XÖV-Fachmodell vorliegen.

6.4.2. NDR-22 (MUSS): Konsistenz von Codelisten in XÖV-Fachmodell und XRepository

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.

6.4.3. NDR-24 (SOLL): Wiederverwendung generischer Nachrichteneigenschaften

Generische Nachrichteneigenschaften sollen einheitlich für alle Nachrichten eines XÖV-Standards genutzt werden.

Erläuterung: Die Nachrichten eines XÖV-Standards besitzen in der Regel implizite oder explizite Nachrichtenköpfe zur Übermittlung generischer Nachrichteneigenschaften, etwa zum Erstellungszeitpunkt oder dem Autor und Leser der Nachricht. Die Inhalte der Nachrichtenköpfe können in der Regel unabhängig vom jeweiligen fachlichen Kontext eingesetzt werden.

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.5. XML Schema-Konformität

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

6.5.1. NDR-28 (MUSS): Valide W3C XSD-Schemata

Alle XSD-Schemata eines XÖV-Standards müssen gültig bezüglich der XML Schema-Spezifikation des W3C sein (siehe www.w3.org/2001/XMLSchema).

Begründung: Ausschließlich technisch valide XSD-Schemata (Stereotyp xsdSchema) 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. == Namensräume und Versionen

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

6.5.2. NDR-29 (MUSS): Identifizierende Namensräume

Alle im Rahmen eines XÖV-Standards definierten globalen XML-Elemente und benannten XML-Typen 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 von XML Schema-Definitionen (Eigenschaft namespace der Stereotypen xsdSchema und xsdXModel) sowie die dazugehörigen Präfixe (Eigenschaft prefix der Stereotypen xsdSchema und xsdXModel).

Begründung: Eindeutige Namensräume sind für die Verwendung von Elementen und Typen eines Standards notwendig.

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

6.5.3. NDR-30 (MUSS): Versionierung der XSD-Schemata

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

Erläuterung: Diese Regel bezieht sich auf das XML Schema-Attribut version (Eigenschaft version der Stereotypen xsdSchema und xsdXModel).

Begründung: Versionen müssen die Entwicklungsstände eines XSD-Schema 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.

6.5.4. NDR-31 (SOLL): Namensräume mit Versionen

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

Erläuterung: Diese Regel bezieht sich auf XML-Namensräume (Eigenschaft namespace der Stereotypen xsdSchema und xsdXModel).

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 zugrundeliegen.

Beispiel: www.xgewerbeanzeige.de/spezifikation/2.1

7. Good Practise

Neben den Regelungen mit den Verbindlichkeitsstufen SOLL und MUSS existieren im Bereich der technischen Ausgestaltung auch sogenannten Good Practise. Sie dokumentieren in der Praxis bewährten Namens- und Entwurfsmustern und können helfen, den Entwicklungsaufwand zu reduzieren sowie die Einheitlichkeit und damit die Zugänglichkeit eines XÖV-Standards zu verbesser. Die in diesem Abschnitt 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.

8. Metadaten eines XÖV-Standards

Tabelle 10. 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 Abschnitt 8.1, “Regelungen zur Bildung von Kennungen” 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.
Version Modellierungswerkzeug [1]	Die Version des Modellierungswerkzeugs, mit dem das XÖV-Fachmodell der Version eines Standards erstellt wurde.
Name Modellierungswerkzeug [1]	Der Name des Modellierungswerkzeugs, mit dem das XÖV-Fachmodell der Version eines Standards erstellt wurde. Wird der Name nicht angegeben, gilt der Standardwert `MagicDraw`.

Standards, welche mit einer XÖV-Profil Version bis einschließlich 3.0.3 erstellt wurden, geben darüber hinaus den verwendeten XGenerator an.

Tabelle 11. Zusätzliche anzugebende Metadaten zu Standards, die mit einem XÖV-Profil bis Version 3.0.3 erstellt wurden
Name [Häufigkeit]	Beschreibung
Metadaten zum Standard
Version XGenerator [1]	Die Version des XGenerators, mit dem das XÖV-Fachmodell der Version eines Standards (mit einer XÖV-Profil Version bis einschließlich 3.0.3) verarbeitet und die Bestandteile der Version des Standards erzeugt wurden.

8.1. 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, XÖV-Kernkomponenten und XÖV-Datentypen 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.^[5] 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, XÖV-Kernkomponenten und XÖV-Datentypen 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 kursiv dargestellten Bestandteile der Kennung sind vom Herausgeber des 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, kernkomponente und datentyp.
Name: Der variable Teil Name stellt den technischen Namen (siehe Tabelle 10, “Metadaten eines XÖV-Standards und seiner Versionen”) des Inhalts dar (z. B. 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 die diese Form überführt werden.

9. XÖV-Bibliothek

In diesem Kapitel wird die Methodik zur Nutzung der XÖV-Bibliothek und der Einbindung ihrer Inhalte beschrieben. Das Spezifikationsdokument zur steht hier zum Download bereit.

TBD

10. Nutzung von XÖV-Datentypen

Hinweis zum XÖV-Primer

Ab XÖV 3.0 wird eine durch die KoSIT empfohlene, vereinfachte Entwicklungsmethodik zur Spezifikation und Produktion eines XÖV-Standards angeboten. Die neuen Möglichkeiten werden im XÖV-Primer-Dokument^[6] beschrieben.

Das XÖV-Handbuch bezieht sich bei den folgenden Erläuterungen auf die vollständige Modellierung, die weiterhin ihre Gültigkeit behält und die technischen Details explizit beschreibt.

XÖV-Datentypen sind grundlegende Bausteine für den Aufbau von XÖV-Standards. Sie liegen als XML-Datentypen vor und können somit direkt in die XML Schema-Definitionen eines XÖV-Standards eingebunden und mittels üblicher XML Schema-Mechanismen genutzt werden. Zu den XÖV-Datentypen gehören die von der KoSIT betriebenen Datentypen, deren UML-Spezifikation in der XÖV-Bibliothek exakt ihrer XML Schema-Definition entspricht, sodass sie reibungslos in einem XÖV-Fachmodell eines XÖV-Standards verwendet werden können. Des Weiteren gehören zu den XÖV-Datentypen Bausteine anderer Standards und Normen, die nicht von der KoSIT betrieben werden, wie beispielsweise Geodatenbausteine der Geography Markup Language (GML), welche von dem internationalen Open Geospatial Consortium (OGC) betrieben wird sowie Inhalte der vom World Wide Web Consortium (W3C) spezifizierten Inhalte des XML-Namensraums (XML namespace). Solche Bausteine liegen nicht als XÖV-konforme UML-Modellelemente vor. Die KoSIT betreibt aus diesem Grund so genannte XÖV-Adapter (im konkreten Falle der GML als GML-Adapter bezeichnet), welche die Anbindung dieser Bausteine über das XÖV-Fachmodell eines XÖV-Standards ermöglichen, sodass sie letztlich auf der XML Schema-Ebene unverändert genutzt werden können. Die Adapter werden in der XÖV-Bibliothek bereitgestellt und in der Spezifikation der Bibliothek entsprechend dokumentiert.

10.1. Datentypen der KoSIT

Von der KoSIT betriebene XÖV-Datentypen können über die folgenden XML Schema-Mechanismen in einem XÖV-Standard genutzt werden: * Direkte Nutzung eines XÖV-Datentyps als Typ eines XML-Elements oder -Attributs. Die folgende Abbildung zeigt beispielhaft die direkte Nutzung des XÖV-Datentyps String.Latin als Typ des XML-Elements name, welches einen allgemeinen Namen repräsentiert.

Ableitung von einem XÖV-Datentyp über eine XML Schema-Restriktion. Im Falle einer Schema-Restriktion wird ein neuer, standardspezifischer Datentyp erstellt, welcher eine Einschränkung des zugrundeliegenden XÖV-Datentyps darstellt. Auf der UML-Ebene wird diese Form der Ableitung mit Hilfe einer Generalisierungsbeziehung modelliert, die mit dem XÖV-Stereotypen «xsdRestriction» annotiert ist. Im Falle der Einschränkung einfacher Datentypen stehen über die Eigenschaften dieses Stereotyps die XML Schema spezifischen Facetten zur Verfügung. Das folgende Beispiel veranschaulicht auf der Basis des XÖV-Datentyps String.Latin die Ableitung eines neuen, restriktiveren Datentyps String.1to50, welcher die Anzahl der zulässigen Zeichen auf 1 bis 50 beschränkt.

Implizite Nutzung des XÖV-Datentyps Code. Ein standardspezifischer Code-Datentyp muss auf der XML Schema-Ebene über eine XML-Restriktion vom XÖV-Datentyp Code ableiten. Auf der Modell-Ebene wird keine Generalisierungsbeziehung zwischen den beiden Datentypen angelegt; sie wird bei der Übersetzung in XML Schema automatisiert erstellt.

Details zum XÖV-Datentyp Code und seiner Verwendung sind in Nutzung von Codelisten beschrieben.

Ableitung von einem XÖV-Datentyp über eine XML Schema-Erweiterung. Analog zur Einschränkung eines Datentyps, kann ein neuer standardspezifischer Datentyp erstellt werden, welcher den ursprünglichen XÖV-Datentyp um zusätzliche XML-Elemente und -Attribute erweitert. Auf der UML-Ebene geschieht dies mittels einer UML-Generalisierungsbeziehung ohne weitere Annotation. Das folgende Beispiel zeigt eine Erweiterung des einfachen Datentyps String.Latin um ein XML-Attribut, welches einer Zeichenfolge eine Sprache zuordnet.

Für die Nutzung eines XÖV-Datentyps auf der XML Schema-Ebene sind weitere Informationen notwendig. Zu ihnen gehört insbesondere der XML Schema-Namensraum, in dem der XÖV-Datentyp definiert ist und häufig auch der Ort, an dem die XML Schema-Definition des Datentyps bezogen werden kann. Diese Informationen sind für jeden XÖV-Datentyp in der XÖV-Bibliothek an dem jeweiligen XML Schema-Paket definiert und werden von den XÖV-Spezifikations- und Produktionswerkzeugen automatisiert verarbeitet. Die folgende Abbildung zeigt beispielhafte Informationen für das XML Schema-Paket zu dem XÖV-Datentyp String.Latin in der Version 1.1.1. Der XÖV-Stereotyp «xsdSchema» stellt entsprechende Eigenschaften, wie namespace und schemaLocation bereit. Die Einbindung des Namensraums eines XÖV-Datentyps in eine XML Schema-Definition des eigenen XÖV-Standards geschieht auf der UML-Ebene mit der Hilfe einer UML-Abhängigkeitsbeziehung, welche mit dem XÖV-Stereotyp «xsdImport» versehen wird.

Je nachdem, ob sich ein XÖV-Standard im Entwicklungszustand befindet (ausgedrückt über den XÖV-Stereotyp «xsdXModel» und seiner Eigenschaft deployment mit dem Wert false) oder vor der Herausgabe steht (deployment mit dem Wert true), werden die XÖV-Datentypen von den XÖV-Spezifikations- und Produktionswerkzeugen unterschiedlich behandelt: Im Entwicklungszustand wird neben den XML Schema-Definitionen des XÖV-Standards für alle genutzten XÖV-Datentypen jeweils eine lokale XML Schema-Definition generiert und über lokale Pfade in die XML Schema-Definitionen des XÖV-Standards importiert. Auf diese Weise kann die Validierung der XML Schema-Definitionen eines XÖV-Standards ohne Zugriff auf externe (z. B. über eine Webadresse beziehbare) Objekte geschehen. Bei der Herausgabe entfällt die Generierung der XML Schema-Definitionen für die XÖV-Datentypen, da ihre online vorliegenden Originalschemata (unter Nutzung der spezifizierten schemaLocation) eingebunden werden.

10.2. Datentypen anderer Standards und Normen (XÖV-Adapter)

Die einheitliche Bereitstellung aller XÖV-Datentypen über die XÖV-Bibliothek und der Betrieb von XÖV-Adaptern ermöglicht auch eine einheitliche Nutzung. Datentypen anderer, nicht im XÖV-Kontext entwickelter XML-Fachstandards und Normen, die häufig nur in XML Schema vorliegen, können somit auf dem gleichen Wege wie die von der KoSIT betriebenen XÖV-Datentypen in XÖV-Standards genutzt werden.

Jeder XÖV-Adapter repräsentiert einen bestimmten Namensraum, wie beispielsweise den der GML-Bausteine oder den XML-Namensraum, und stellt die darin spezifizierten XML Schema-Elemente, -Attribute und -Typen auf der UML-Ebene zur Verfügung. Die Bestandteile eines XÖV-Adapters liegen somit genau wie Datentypen der KoSIT als UML-Klassen vor, die über das XÖV-Profil auf erwartete Weise als XML-Elemente, -Attribute oder -Typen gekennzeichnet sind. Die Nutzung der Bestandteile eines XÖV-Adapters führt auf der XML Schema-Ebene zu einer direkten Nutzung der Elemente, Attribute und Typen aus dem fremden Namensraum.

Der einzige Unterschied zu den Datentypen der KoSIT besteht in der Präsentationsform der XÖV-Adapter. Bestandteile eines XÖV-Adapters liegen ohne Informationen zu ihren inneren Strukturen (bestehend aus XML-Elementen und -Attributen) und ohne semantische Beschreibung (Dokumentation) vor. Sie dienen ausschließlich der Nutzung in XÖV-Standards. Bedeutung und Details der Datentypen sind dem zugrundeliegenden Standards bzw. der jeweiligen Norm zu entnehmen.

Die folgende Abbildung gibt einen Einblick in die aktuell angebotenen XÖV-Adapter, die einen direkten Zugriff auf Geodatenbausteine (Geography Markup Language) und den XML-Namensraum (XML namespace) erlaubt. Der GML-Adapter ermöglicht eine Anbindung der Datentypen der Geography Markup Language in der Version 3.2, zu denen beispielsweise die XML-Elemente MultiPoint und Point gehören. Neben dem Namen der Elemente und ihrer Deklaration als solche liegen, wie zuvor erläutert, keine weiteren Informationen vor.

Im Standard XZuFi wird beispielsweise eines der beiden zuvor genannten Elemente als Bestandteil eines standardspezifischen Geodatenbausteins genutzt.

Die Deklaration der Nutzung des GML-Namensraums in dem Namensraum des eigenen XÖV-Standards geschieht ebenso auf üblichem Wege über den XÖV-Stereotyp «xsdImport» (siehe folgende Abbildung).

Das vorherige Beispiel zeigt eine XÖV-Adapter spezifische Erweiterung des genannten Stereotypen: Die Bestandteile eines XÖV-Adapters werden im Rahmen des XÖV-Produktionsprozesses nicht verarbeitet und somit keine XML Schema-Definitionen für sie in der Entwicklungsphase eines XÖV-Standards generiert. Damit während der Entwicklungsphase dennoch eine lokale Validierung der XML Schema-Definitionen des XÖV-Standards möglich ist, erlaubt die Eigenschaft schemaLocationLocal die Angabe eines lokalen Pfades zum Ablageort der Originalschemata, z. B. der GML-Schemata. Relative Pfade mit dem Generierungsverzeichnis für die XML Schema-Definitionen des XÖV-Standards (./build/xsd/) als Ausgangspunkt sind möglich.

11. Nutzung von XÖV-Kernkomponenten

Die Methodik zur Nutzung der XÖV-Kernkomponenten unterscheidet sich grundlegend von der Methodik für die XÖV-Datentypen, da XÖV-Kernkomponenten in XÖV-Standards je nach Bedarf und mit verschiedenen Freiheitsgraden genutzt werden können, von der Ausprägung einer losen semantischen Verbindung bis hin zur Wiederverwendung von Strukturen in XML Schema.

11.1. Überblick über die Methodik

Der Ansatz zur Nutzung der XÖV-Kernkomponenten ist, wie in XÖV-Bausteine beschrieben, weniger strikt bei deren Verwendung, kann dabei jedoch die Sichtbarkeit und Vergleichbarkeit der Bausteine von XÖV-Standards verbessern und auf diese Weise die Harmonisierung von XÖV-Standards unterstützen. Der Weg zur Realisierung dieser Möglichkeiten ist dreiteilig:

XÖV-Vorhaben zeichnen die Beziehungen zu den XÖV-Kernkomponenten aus: In der Regel beinhalten XÖV-Standards Bausteine, die als Ausprägung der Kernkomponenten betrachtet werden können. Die spezifischen Anforderungen des XÖV-Vorhabens können es erfordern, dass einzelne Kernkomponenten nur in angepasster Form wiederverwendet werden können.

Im Kontext der neuen Methodik zur Nutzung der Kernkomponenten haben XÖV-Vorhaben die Aufgabe die Beziehungen der Bausteine ihres Standards zu den XÖV-Kernkomponenten explizit zu dokumentieren, indem sie ihre Bausteine mit der Hilfe des XÖV-Profils entsprechend auszeichnen.

Die XÖV-Koordination verarbeitet die Auszeichnungen: Die ausgezeichneten Bausteine eines XÖV-Standards werden von der XÖV-Koordination verarbeitet und mit den Informationen anderer XÖV-Standards verknüpft.
Die XÖV-Koordination stellt die Auswertungsergebnisse über die InteropMatrix dar Die Ergebnisse der Auswertung werden in aufbereiteter Form veröffentlicht. Hierfür wird die sogenannte InteropMatrix genutzt. Die InteropMatrix stellt somit die zentrale Anlaufstelle dar, wenn es darum geht sich über die fachliche Ausgestaltung anderer XÖV-Standards (zum Beispiel zukünftiger Kommunikationspartner) sowie ihrer Unterschiede und Gemeinsamkeiten zu informieren.

Die Auszeichnung der Bausteine eines XÖV-Standards beinhaltet die Identifikation von Abweichungen gegenüber der jeweiligen XÖV-Kernkomponente und die Beschreibung der fachlichen Anforderungen, die zu der Abweichung geführt haben. Die Begründungen etwaiger Abweichungen haben grundsätzlich keinen rechtfertigenden Charakter, sondern geben der XÖV-Koordination und anderen XÖV-Vorhaben aufschlussreiche Informationen und Einblick in die eigenen Vorgaben. Gleichzeitig soll die Auszeichnung der Bausteine ein Bewusstsein für mögliche Harmonisierungsmöglichkeiten schaffen, wenn beispielsweise fachlich unbegründete Abweichungen entdeckt werden.

Nicht nur bestehende XÖV-Vorhaben profitieren von den Informationen der Auszeichnung. Insbesondere auch neuen XÖV-Vorhaben dienen die XÖV-Kernkomponenten und die mit ihnen verwandten fachspezifischen Bausteine als Grundlage der Neuentwicklung interoperabler und qualitativ hochwertiger fachlicher Bausteine. Dasselbe gilt für Projekte zur Erweiterung von XÖV-Standards. Für eine komfortable Entwicklung stehen über die XÖV-Bibliothek passend aufbereitete Bausteinvorlagen zur Verfügung.

Die in diesem Abschnitt überblickten Aspekte werden in den folgenden Abschnitten genauer erläutert und anhand verschiedener Beispiele aus der Praxis veranschaulicht.

11.2. Aufbau und Informationsgehalt

XÖV-Kernkomponenten beschreiben die Semantik und Struktur verschiedener, in der öffentlichen Verwaltung zu übermittelnder Informationen, wie Namen oder Anschriften. Im Gegensatz zu den XÖV-Datentypen weisen die XÖV-Kernkomponenten in ihrer UML-Darstellung keine XML Schema spezifischen Annotationen auf. Die folgende Abbildung soll die anschließenden Ausführungen veranschaulichen.

Eine XÖV-Kernkomponente (zum Beispiel AllgemeinerName) wird als aggregierte Kernkomponente (Aggregated Core Component, ACC) gekennzeichnet. Sie weist sowohl eine semantische Beschreibung (Dokumentation der UML-Klasse) auf, als auch einzelne Eigenschaften auf, die wiederum eigene semantische Beschreibung besitzen.

Die Eigenschaften einer Kernkomponente können auf XÖV-Datentypen bzw. den XML Schema-Datentypen des XÖV-Profils basieren. In diesem Fall werden sie als Basiskernkomponenten (Basic Core Component, BCC) bezeichnet und als UML-Attribute modelliert. Die in Kernkomponente zum allgemeinen Namen dargestellte Kernkomponente besitzt die drei Basiskernkomponenten name, nichtVorhanden und namensart.

Im Allgemeinen machen die XÖV-Kernkomponenten konkrete Vorgaben zu den Datentypen der Basiskernkomponenten (xoevBCC). Basiskernkomponenten mit dem Datentyp Code bedürfen jedoch in der Regel einer Konkretisierung im Hinblick auf die Verwendung einer bestimmten Codeliste. Zum Beispiel wird die namensart des allgemeinen Namens, so schlägt es die Basiskernkomponente vor, über Codes aus einer Codeliste bestimmt. Die konkrete Codeliste wird an dieser Stelle jedoch nicht benannt.

Eigenschaften einer Kernkomponente, die eine aggregierte Kernkomponente als Typ haben, also eine komplexe Struktur besitzen, werden Assoziationskernkomponenten (Association Core Component, ASCC) genannt. Die komplexe Eigenschaft alternativeRepraesentation des allgemeinen Namens basiert beispielsweise auf der Kernkomponente AlternativeRepraesentation und deren Eigenschaften.

11.3. Auszeichnung der Beziehungen

Die Auszeichnung der Beziehungen der Bausteine eines Standards zu den XÖV-Kernkomponenten kann in drei Aktivitäten von Seiten der XÖV-Vorhaben untergliedert werden. Diese werden in den folgenden Unterabschnitten erläutert.

11.3.1. Identifikation der relevanten Bausteine

Die Auszeichnung der Beziehungen zu den einzelnen XÖV-Kernkomponenten geschieht für alle Bausteine eines XÖV-Standards, welche die im Folgenden aufgeführten Bedingungen erfüllen. Diese Bausteine sind in einem ersten Schritt zu identifizieren:

Der Baustein repräsentiert einen komplexen, benannten XML-Typen, oder ein globales XML-Element.
Er ist Bestandteil des XÖV-Standards, das heißt dessen XML-Namensräume. Hierzu gehören auch Bausteine, die von Bausteinen fremder Standards abgeleitet sind.
Die semantische Beschreibung des Bausteins entspricht der einer aggregierten XÖV-Kernkomponente (xoevACC) bzw. ist mit dieser vergleichbar. Der Name und der strukturelle Aufbau des Bausteins sind an dieser Stelle nicht relevant.

Im Gegensatz zu den ersten beiden Bedingungen lässt die dritte Bedingung einen Interpretationsspielraum, der nach Ermessen der fachlichen Experten eines XÖV-Vorhabens behandelt werden kann. In vielen Fällen ist eine Beziehung jedoch direkt erkennbar.

11.3.2. Kennzeichnung der Beziehungen

Ein Baustein, für den eine semantische Beziehung zu einer XÖV-Kernkomponente identifiziert wurde, wird durch den XÖV-Stereotyp «xoevABIE» gekennzeichnet.^[7] Falls der Name des Bausteins mit dem der XÖV-Kernkomponente (xoevACC) übereinstimmt, ist deren Beziehung bereits eindeutig bestimmt und eine weitere Kennzeichnung auf dieser Ebene nicht notwendig. Andernfalls ist die Beziehung des Bausteins zur Kernkomponente mittels einer UML-Abhängigkeitsbeziehung zu kennzeichnen. Die folgende Abbildung zeigt zwei standardspezifische Bausteine, die mit der Kernkomponente Anschrift in Beziehung stehen.

In einem weiteren Schritt werden die Eigenschaften des Bausteins betrachtet und mit denen der XÖV-Kernkomponente verglichen. Für jede Eigenschaft des betrachteten Bausteins, deren semantische Beschreibung mit der einer Eigenschaft (xoevBCC oder xoevASCC) der Kernkomponente vergleichbar ist, ist eine Beziehung auszuzeichnen. Bei dieser Betrachtung sind Name und Typ der Eigenschaft nicht von Bedeutung.

Eine Bausteineigenschaft (UML-Attribut, oder Rolle einer UML-Assoziation), die mit einer Kernkomponenteneigenschaft in Beziehung steht, wird mit dem XÖV-Stereotyp «xoevBBIE» gekennzeichnet, falls sie keine komplexe Strukturen aufweist, z. B. bei der Verwendung des Datentyps String.Latin oder Code. Bausteineigenschaften mit komplexen Strukturen werden als «xoevASBIE» gekennzeichnet.

Bei Namensunterschieden ist auch für Eigenschaften mittels einer UML-Abhängigkeitsbeziehung eine explizite Verbindung herzustellen. Die folgende Abbildung zeigt eine beispielhafte Situation.

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 Practise

2.2. XÖV-Bausteine

2.2.1. XÖV-Datentypen

2.2.2. XÖV-Kernkomponenten

2.2.3. XÖV-Codelisten

2.3. Werkzeuge

2.3.1. XÖV-Produktionsumgebung

2.3.2. XÖV-Profil

2.3.3. XGenerator

2.4. Infrastruktur

2.4.1. XRepository

2.4.2. XÖV-Bibliothek

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-11 SOLL: Nutzung der XÖV-Kernkomponenten

K-12 SOLL: Nutzung der XÖV-Datentypen

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. Prüfung der XÖV-Konformität

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

4.3.3. Ablauf des Produktionsprozesses

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 Konfiguration

5.2.2. Sprachelement Metadaten

5.2.3. Sprachelement Externe Inhalte

5.2.4. Sprachelement Bausteine

5.2.5. Sprachelement Codeliste

5.2.6. Sprachelemente Paket und Schemapaket

5.3. Regelungen zur Ausgestaltung des XÖV-Fachmodells

6. XÖV-Namens- und Entwurfsregeln

6.1. Strukturen und Inhalte

6.1.1. NDR-1 (MUSS): Konsistente Inhalte in XÖV-Fachmodell und technischen Bestandteilen des Standards

6.1.2. NDR-2 (MUSS): Hauptstruktur eines XÖV-Fachmodells

6.1.3. NDR-3 (MUSS): Nachrichten als globale Elemente

6.1.4. NDR-4 (SOLL): Erlaubte Einbindungsarten für Codelisten

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

6.2.1. NDR-11 (SOLL): Erlaubte Zeichen für Namen

6.2.2. NDR-13 (SOLL): Versionsübergreifend eindeutige Nachrichtennamen

6.3. Dokumentation

6.3.1. NDR-32 (MUSS): Dokumentation der Metadaten des Standards

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-11 `SOLL`: Nutzung der XÖV-Kernkomponenten

K-12 `SOLL`: Nutzung der XÖV-Datentypen

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

5.2.1. Sprachelement `Konfiguration`

5.2.2. Sprachelement `Metadaten`

5.2.3. Sprachelement `Externe Inhalte`

5.2.4. Sprachelement `Bausteine`

5.2.5. Sprachelement `Codeliste`

5.2.6. Sprachelemente `Paket` und `Schemapaket`