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. Er beschreibt die Grundlagen, den Aufbau und die intendierte Verwendung des XÖV-Standardisierungsrahmens und stellt die damit verbundenen Anforderungen und Nutzenpotenziale dar.

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

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

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

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:

TBD

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

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

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

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.

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.

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.

Bausteine sind Datenstrukturen eines Standards, die mehrfach innerhalb des eigenen Standards, aber auch Standard-übergreifend verwendet werden können. Ergänzend dazu kann ein 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.

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

XÖV-Produkte sind einzelne oder zusammengefasste Komponenten des XÖV-Standardisierungsrahmens, wie beispielsweise der XGenerator, die XÖV-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.

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

Es wird zwischen den Verbindlichkeitsstufen MUSS und SOLL unterschieden:

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.

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

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

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

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

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

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.

Administrative Informationen wie beispielsweise der Name, die Kennung oder die Beschreibung eines Standards werden im Kontext des XÖV-Standardisierungsrahmens als Metadaten bezeichnet. Sie werden 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 Anhang C, .

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

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

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

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

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

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

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

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

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.

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

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

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

Die XÖV-Modellierungssprache wird zur Modellierung 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 Sprachelemente in einem XÖV-Fachmodell kombiniert werden können.

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

Mit XÖV classic und XÖV lite stehen zwei alternative, gleichwertige Notationen der XÖV-Modellierungssprache zur Verfügung. 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 unterstützt. Beispiel 1, “Datentyp in XÖV-Notationen” zeigt beispielhaft die Spezifikation eines Datentyps in XÖV lite und XÖV classic .

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

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.

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

Begründung: Im Kontext eines XÖV-Standards 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 XSD-Schemas des XÖV-Standards als Nachricht spezifiziert ist.

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

Eine Codeliste soll ausschließlich mittels der in Kapitel 11, 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.

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

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

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.

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

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

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.

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

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

Begründung: Mit den Metadaten eines XÖV-Standards und seiner Version werden grundlegende fachliche und technische Informationen zum Standard dokumentiert. Die Angabe der Metadaten im XÖV-Fachmodell erlaubt Mensch (z. B. Nutzern des Standards und der XÖV-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.

Alle Bestandteile eines XÖV-Standards sollen 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.

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.

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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.

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.

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.

Die XÖV-Bibliothek wird in unterschiedlichen Editionen für die Notationen XÖV-classic (MagicDraw und Papyrus) und XÖV-lite bereitgestellt. Sie wird wie in Abschnitt "Sprachelement Externe Inhalte" beschrieben und in NDR-2 "Hauptstruktur eines XÖV-Fachmodells" geregelt, als externes Modell in das Fachmodell eingebunden. Durch die Einbindung der XÖV-Bibliothek können alle enthaltenen XÖV-Bausteine auf die gleiche Weise verwendet werden wie die eigenen Inhalte im XÖV-Fachmodell.

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

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

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

In XÖV classic stehen damit direkt beim Öffnen des XÖV-Fachmodells alle neuen Versionen der XÖV-Bausteine zur Verfügung. In XÖV lite ist zusätzlich die neue Fassung des nun eingesetzten Standes der XÖV-Bibliothek im XÖV-Fachmodell anzugeben (Notationselement fassung in externesModell).

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

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

Die folgende Abbildung veranschaulicht anhand der Notation XÖV classic einen Vorgang aus der Praxis. Das XInneres-Fachmodul XPersonenstand nutzt das XInneres-Basismodul mit vereinheitlichten Bausteinen für Standards der Innenverwaltung. Sowohl XPersonenstand, als auch das Basismodul nutzen den XÖV-Datentyp Code. Sollte zukünftig eine neue Version dieses Datentyps entstehen, könnte der Fall eintreten, dass XPersonenstand auf diese Version umsteigt, jedoch noch kein aktualisiertes XInneres-Release existiert, sodass die eingebundene XInneres-Version weiterhin den alten Code-Datentyp nutzt. Trotzdem bindet XPersonenstand ausschließlich die aktuellste Fassung der XÖV-Bibliothek ein und muss somit keine gesonderte Fassung für XInneres vorhalten.

Die von der XÖV-Koordination betriebenen XÖV-Datentypen können grundsätzlich auf die gleiche Weise und im gleichen Umfang wie die Datentypen des eigenen Standards genutzt werden, wenn die XÖV-Bibliothek wie in Abschnitt "Nutzung der XÖV-Bibliothek" beschrieben als externes Modell in das XÖV-Fachmodell eingebunden ist. Folgende Möglichkeiten der Nutzung stehen zur Verfügung:

XÖV-Datentypen können als Typen lokaler und globaler Eigenschaften eingesetzt werden. Die folgende Abbildung zeigt beispielhaft die direkte Nutzung des XÖV-Datentyps datatypeC der Norm DIN 91379 als Typ des lokalen XML-Elements name.

In der Notation XÖV lite wird der genutzte Datentyp datatypeC mit der Angabe des Präfix din91379 eindeutig bezeichnet, da die XÖV-Bibliothek genau einen Datentyp mit dem Namen datatypeC in einem Schemapaket mit dem Präfix din91379 enthält. Die eindeutige Angabe mittels Präfix ist erforderlich, da alleinstehende Namen mehrdeutig sein können. Der Datentyp datatypeC liegt in der XÖV-Bibliothek einmal als Datentyp einer DIN-Norm vor (Präfix: din91379) und einmal als Datentyp einer DIN-Spec (Präfix: dinspec91379). In XÖV classic wird die eindeutige Bezieheung zwischen nutzender Eigenschaft und genutztem XÖV-Datentyp mit UML-Mitteln sichergestellt.

Neben der Nutzung in lokalen Eigenschaften, können XÖV-Datentypen wie im folgenden Beispiel gezeigt auch in globalen Eigenschaften (in diesem Fall in einem globalen XML-Element) genutzt werden:

In XÖV classic wird der Datentyp mittels einer UML-Abhängigkeitsbeziehung modelliert, die mit dem Stereotyp xsdGlobalElementType annotiert wird. In XÖV lite erfolgt die Angabe mittes des Attributs typ.

Im Falle einer Schema-Restriktion wird ein neuer, standardspezifischer Datentyp erstellt, welcher eine Einschränkung des zugrundeliegenden XÖV-Datentyps darstellt. In XÖV classic wird diese Form der Ableitung mit Hilfe einer UML-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 (z. B. "minLength" und "maxLength"). In XÖV lite wird der Basistyp mittels des Attributs basistyp angegeben und mittels des Attributs restriction die Tatsache, dass eine Einschränkung vorliegt, gekennzeichnet. Das folgende Beispiel veranschaulicht auf der Basis des XÖV-Datentyps datatypeC die Ableitung eines neuen, restriktiveren Datentyps String.1to50, welcher die Anzahl der zulässigen Zeichen auf 1 bis 50 beschränkt.

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. In XÖV classic geschieht dies mittels einer UML-Generalisierungsbeziehung ohne weitere Annotation. In XÖV lite können die Erweiterungen mittels Angabe des Basistyps und der zusätzlichen Angabe von weiteren Eigenschaft-Elementen ein XÖV-Datentyp erweitert werden. Das folgende Beispiel zeigt eine Erweiterung des einfachen Datentyps datatypeC um ein XML-Attribut, welches einer Zeichenfolge eine Sprache zuordnet.

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 XÖV-Koordination 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. Für XÖV classic werden die darin spezifizierten XML-Elemente, -Attribute und -Datentypen auf der UML-Ebene zur Verfügung gestellt. Die Bestandteile eines XÖV-Adapters liegen somit genau wie Datentypen der XÖV-Koordination als UML-Klassen vor, die entsprechend 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. Für XÖV lite liegen die Inhalte der XÖV-Adapter im <paket name="XOEV-Adapter"> der XÖV-Bibliothek als entsprechende Datentypen und globale Eigenschaften vor.

Der einzige Unterschied zu den Datentypen der XÖV-Koordination 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. Die Darstellung der Anordnung der Datentypen und globalen Eigenschaften in lite weicht von der classic ab.

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