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.

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:

Siehe Kapitel 1, .

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.

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

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.

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

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.

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

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.

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.

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

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 XSD-Schemata eines XÖV-Standards basieren auf der von dem W3C empfohlenen XML Schema-Definitionssprache.

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.

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.

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.

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

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.

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.

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:

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

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.

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.

Bei Neuentwicklungen und Erweiterungen von XÖV-Standards sind häufig fachliche Bausteine involviert, für deren Abstimmung und Ausgestaltung die XÖV-Kernkomponenten als standardisierte, umfassend dokumentierte Bausteine eine passende Grundlage darstellen können. In diesem Abschnitt wird erläutert wie neue, standardspezifische Bausteine auf der Basis der XÖV-Kernkomponenten erstellt werden können.

Die XÖV-Kernkomponenten machen bereits sehr konkrete Vorschläge zur Ausgestaltung fachlicher Bausteine: Neben allgemeiner Semantik und Struktur schlagen sie konkrete Namen, Datentypen und mögliche Multiplizitäten vor. Grundsätzlich reichen diese Informationen für die Modellierung eines neuen, mit den Kernkomponenten kompatiblen Bausteins aus. Für eine effizientere Modellierung stellt die XÖV-Koordination in der XÖV-Bibliothek für jede Kernkomponente eine Bausteinvorlage zur Verfügung, welche neben Inhalten der Kernkomponente einen konkreten Vorschlag zur Ausgestaltung auf der XML Schema-Ebene macht.

Das folgende Beispiel zeigt auf der linken Seite zwei Kernkomponenten, auf der rechten Seite die für sie bereitgestellten Bausteinvorlagen zur direkten Übernahme in den eigenen Standard.

Eine Bausteinvorlage kann kopiert und in den eigenen XÖV-Standard eingefügt werden. Daraufhin kann auf seiner Basis die Anpassung an die jeweiligen fachlichen Anforderungen geschehen, z. B. nicht benötigte Eigenschaften gestrichen, Datentypen konkretisiert, oder Multiplizitäten verschärft werden. Die Bausteinvorlage ist bereits derartig ausgezeichnet, dass ihre Beziehung zur betrachteten Kernkomponente eindeutig beschrieben ist. Falls Anpassungen der kopierten Vorlage zu Abweichungen gegenüber der Kernkomponente führen, erfordern diese, wie in den vorherigen Abschnitten beschrieben, eine entsprechende Behandlung.

Bei der Nutzung einer Bausteinvorlage ist zu berücksichtigen, dass diese häufig mit anderen Bausteinvorlagen (als Datentypen für ihre Eigenschaften) verknüpft ist. Dementsprechend müssen entweder verknüpfte Bausteinvorlagen in den eigenen XÖV-Standard übernommen, oder diese durch Bausteine des eigenen Standards ersetzt werden. Beispielhaft bedeutet dies, dass bei der Nutzung der Bausteinvorlage AllgemeinerName entweder die Vorlage AlternativeRepraesentation übernommen wird, oder für die Eigenschaft alternativeRepraesentation ein anderer Datentyp gewählt wird.

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

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

Redaktionelle Anpassungen wurden vorgenommen.

Wesentliche Änderungen des XÖV-Standardisierungsrahmens betreffen die Vorbereitung der XÖV-Produkte für ihren zusätzlichen Einsatz in dem Open-Source-Modellierungswerkzeug Papyrus sowie die Umsetzung und Dokumentation einer vereinfachten, modellgetriebenen Entwicklungsmethodik zur Spezifikation und Produktion eines XÖV-Standards. Die aktualisierte Methodik wird hauptsächlich im neu geschaffenen XÖV-Primer-Dokument beschrieben, welches einen leichten Einstieg in die praktische Entwicklung eines XÖV-Standards ermöglichen soll. In das XÖV-Handbuch wurden an den erforderlichen Stellen Hinweise auf das Modellierungswerkzeug Papyrus und den XÖV-Primer aufgenommen.

In der Erläuterung der NDR-3 wurde der Verweis auf den Stereotyp xsdGlobalElement entfernt, da dieser nicht mehr zur Annotation einer Nachricht benötigt wird.

Der Begriff “XÖV-Primer” wurde in das Glossar aufgenommen.

Die Kurzbeschreibung zu NDR-9 in der Tabelle “Übersicht der Regeln und Empfehlungen” wurde geändert in “Umgang mit speziellen Anforderungen an die Nutzung von Codelisten”. (Issue Public 33)

Im Abschnitt “XÖV-Datentypen” wurde ein Bezug zur neu eingeführten XÖV-Basisnachricht hergestellt.

In Abschnitt 8.3.2. “Modellierung spezieller Anforderungen” wurde der neue Abschnitt “Nutzung mehrsprachiger Codelisten” aufgenommen. (Issue 43)

In Abschnitt 2.3.2. “XGenerator” wurde der Verweis auf die XMI-Version “Eclipse UML2 v4.x” geändert in “Eclipse UML2 v5.x”. (Issue 45)

Im Appendix B “Glossar” Hinweis auf die Abschaltung des Genericoders eingefügt. (Issue 42)

Abschnitt 2.2.1. "XÖV-Datentypen" und Kapitel 6. "Nutzung von XÖV-Datentypen" wurden um Aussagen zum neuen XÖV-Adapter "XML namespace" erweitert. (Issue 37)

In der NDR-Tabelle “Übersicht der Regeln und Empfehlungen” wurde die Angabe zur Verbindlichkeit der NDR-12 korrigiert. Sie entspricht nun der tatsächlichen Verbindlichkeit der NDR (EMPFEHLUNG). (Issue 38)

In den Konformitätskriterien K-1 und K-15 wurden die Prüfgrundlage und der Prüfinhalt aktualisiert. Dabei wurden Aussagen zum XÖV-Steckbreif entfernt. (Issue 3)

In der Beschreibung von NDR-33 wurde ein redundanter Absatz entfernt. (Issue 4)

Aus der Tabelle 4.1. “Übersicht der Metadatenelemente eines Standards und seiner Versionen” wurden die Metadatenelemente entfernt, die automatisiert erhoben oder im XRepository eingetragen werden. (Issue 8)

NDR-34 (Modellierung von Codelistenversionen als benannte Typen) wurde neu erstellt (Issue 10).

Prüfinhalt und Begründung wurden in Konformitätskriterium K-9 redaktionell angepasst. (Issue 11)

NDR-24 wurde hinsichtlich der Möglichkeiten zur Wiederverwendung generischer Nachrichteneigenschaften offener gestaltet. (Issue 12)

Im Kapitel “Nutzung von Codelisten” wurden die Abschnitte “Codelisten im XÖV-Fachmodell”, “Kennzeichnung über Code-Typ 4 genutzter Codelisten(versionen)” und “Kennzeichnung der Nutzung von Codelisten ohne Code-Datentyp” neu aufgenommen. Aufgrund der neuen NDR-34 wurden darüber hinaus die Beispiele auf benannte Typen für Codelistenversionen umgestellt und der Abschnitt “Nutzung von Codelistenversionen als anonyme Datentypen” neu aufgenommen. Der Abschnitt “Nutzung von Codelistenversionen als benannte Datentypen” wurde grundlegend inhaltlich überarbeitet. Die Abschnitte wurden neu angeordnet. (Issue 26)

NDR-33 wurde bezüglich der neuen Codelisten-Methodik konkretisiert. (Issue 28)

Auf die XÖV-Webseite "Gültige XÖV-Konfigurationen" wird nun im einleitenden Text des Abschnitts 4.3. “XÖV-Namens- und Entwurfsregeln” verwiesen. Die Einzelverweise in den jeweiligen NDR-Abschnitten wurden entfernt. (Issue 29)

In Abschnitt “Verwendete Standards” wurde die Tabelle aktualisiert.

In Abschnitt “Ansprechpartner und Mitwirkende” wurde die Tabelle aktualisiert.

Das Kapitel “Einleitung” wurde redaktionell angepasst.

Das gesamte Handbuch wurde aufgrund der Ablösung des InteropBrowsers durch die Interopmatrix (hauptsächlich redaktionell) überarbeitet.

Der Abschnitt “XÖV-Bausteine” (im Abschnitt “XÖV-Standardisierungsrahmen”) wurde redaktionell angepasst.

Der Abschnitt “XÖV-Datentypen” (im Abschnitt “XÖV-Bausteine”) wurde aufgrund neuer Datentypen überarbeitet und erweitert.

Der Abschnitt “XÖV-Codelisten” (im Abschnitt “XÖV-Bausteine”) wurde inhaltlich überarbeitet.

Der Abschnitt “InteropBrowser” (im Abschnitt “Werkzeuge”) wurde entfernt.

Der Abschnitt “XGenerator” (im Abschnitt “Werkzeuge”) wurde bzgl. der unterstützten XMI-Version konkretisiert.

Der Abschnitt “XRepository” (im Abschnitt “Infrastruktur”) wurde um Aussagen zur Interopmatrix erweitert.

Das Konformitätskriterium K-4 wurde um die Anforderung ergängt, dass alle durch den Standard genutzten Codelisten, wenn sie durch den Standard herausgegeben werden, im XRepository veröffentlicht sein müssen.

Konformitätskriterium K-6 und K-7 wurden aufgrund der Ersetzung des XÖV-Steckbriefs durch direkte Angaben im XRepository überarbeitet.

In Konformitätskriterium K-12 wurde die Vorgabe zur Nutzung der jeweils aktuellen Version gestrichen.

Das Konformitätskriterium K-13 “Nutzung von Codelisten” wurde inhaltlich aktualisiert.

Konformitätskriterium K-15 wurde redaktionell angepasst.

In Abschnitt “Prüfung der XÖV-Konformität” wurde die Aussage zu Canonical XMI gestrichen.

In Abschnitt “XÖV-Spezifikations- und Produktionsprozess” wurde Aufzählungspunkt 3. um weitere Bestandteile ergänzt.

An allen Stellen wurden im Fließtext die spitzen Klammern um Stereotyp-Namen entfernt.

Abschnitt “Produktion eines XÖV-Standards” wurde um Genericode-Elemente und weitere Elemente als Überführungsergebnis ergänzt.

In Abschnitt “Erstellung des Spezifikationsdokuments” wurde ein Beispiel hinzugefügt.

NDR-1 wurde um Aussagen zu “Strukturen” bereinigt.

In NDR-2 wurden in Aufzählungspunkt a. Vorgaben zum Namen des Modells gestrichen und in Aufzählungspunkt b. Codelisten-Modelle aufgenommen. Darüber hinaus wurde das Beispiel aktualisiert.

In NDR-5 wurde eine Vorgabe zur Benennung des Modells ergänzt.

NDR-8 “Versionsübergreifend eindeutige Codes in Codelisten” wurde aufgrund ihrer Überführung in das Codelisten-Handbuch gestrichen.

In Abschnitt “XÖV-Namens- und Entwurfsregeln” wurde der Abschnitt “Namen” umbenannt in “Namen für XML-Attribute, -Elemente und -Typen”.

NDR-10 “Konsistente Namen in XÖV-Fachmodell und XML Schema-Definitionen” wurde gestrichen, da sie durch die aktualisierte NDR-1 abgedeckt ist.

NDR-12 wurde in eine Empfehlung überführt.

In NDR-18 wurde bzgl. der Nutzung des technischen Namens aktualisiert.

NDR-22 wurde hinsichtlich Konsistenz von Codelisten in XÖV-Fachmodell und XRepository konkretisiert.

NDR-33 “Codelisten konform zu den Regelungen des Codelisten-Handbuchs” wurde neu erstellt.

NDR-31 wurde um eine Aussage zum Versionierungskonzept ergänzt und das enthaltene Beispiel aktualisiert.

Das Kapitel “XÖV-Bibliothek” wurde redaktionell überarbeitet.

Der Abschnitt “Datentypen der KoSIT” wurde aufgrund einer neuen Codelisten-Methodik im Bereich “Ableitung von einem XÖV-Datentyp über eine XML Schema-Restriktion” überarbeitet und um den Bereich “Implizite Nutzung des XÖV-Datentyps Code.” ergänzt.

In Abschnitt “Datentypen anderer Standards und Normen (XÖV-Adapter)” wurden die Beispiele ausgetauscht und der Abschnitt redaktionell angepasst.

Die Abbildung “Einschränkung des Datentyps einer Basiskernkomponente (xoevBCC)” wurde aktualisiert.

Das Kapitel “Nutzung von Codelisten” wurde aufgrund einer neuen Codelisten-Methodik komplett überarbeitet. Teile des Kapitels wurden in das Codelisten-Handbuch verlagert.

Der Anhang “Mitwirkende” wurde ergänzt.

Der Anhang “XÖV-Glossar” wurde aktualisiert.

Zukünftig wird anstelle der XÖV-Website "Spezifikations- und Produktionswerkzeuge" auf die Website "Gültige XÖV-Konfigurationen" verwiesen.

Das Konformitätskriterium K-3 “Dokumentation” wurde um Vorgaben zur Angabe von Metadaten erweitert. In der neuen Namens- und Entwurfsregel NDR 32 “Dokumentation der Metadaten des Standards” werden die Vorgaben konkretisiert. Darüber hinaus wurden die Einleitung des Handbuchs um Aussagen zu Metadaten eines Standards erweitert und der Abschnitt “Metadaten eines XÖV-Standards” neu in das Kapitel “Spezifikation und Produktion von XÖV-Standards” aufgenommen. Der Unterabschnitt “Regelungen zur Bildung von Kennungen” des neuen Abschnitts ersetzt und verallgemeinert den früheren “Leitfaden zur Bildung von Uniform Resource Names” aus dem Kapitel “Bereitstellung und Nutzung von Codelisten”. (CR 667)

Der Abschnitt "Abbildung von Metadaten" im Kapitel "Bereitstellung und Nutzung von Codelisten" ist hinsichtlich der verfügbaren Metadatenelemente einer Codeliste und deren Abbildung in Genericode aktualisiert und erweitert worden. Die zugehörigen Beispiele zur Abbildung von Codelisten wurden dementsprechend aktualisiert. (CR 668)

Die Metadaten von Codelisten und die Inhalte von Codelisten (in der Code-Spalte und bis zu zwei Beschreibungsspalten) werden im XÖV-Fachmodell eines Standards zukünftig vollständig dokumentiert. Dementsprechend ändert sich die Methodik der Modellierung und Nutzung von Codelisten, sodass der Abschnitt "Nutzung von Codelisten" im Kapitel "Bereitstellung und Nutzung von Codelisten" diesbezüglich überarbeitet wurde. (CR 669)

Der Abschnitt "Nutzung weiterer Genericode-Funktionalitäten" wurde in das Kapitel "Bereitstellung und Nutzung von Codelisten" neu aufgenommen. Mit diesem Abschnitt wird explizit dargelegt, welche Elemente und Attribute des Genericode-Standards durch den XÖV-Standardisierungsrahmen und dessen Produkte nicht unterstützt werden. (CR 474)

Die Übergangsfrist zur Gültigkeit der XÖV-Regelungen wurde auf 36 Monate erhöht. Hierzu wurde das Kapitel 3 “XÖV-Konformität” aktualisiert. (CR 526)

Für das XÖV-Konformitätskriterium K-5 “Nachhaltigkeit des Standards” wurden die Angaben zum Prüfinhalt um die für die Pflege zuständige Stelle erweitert. (CR 512)

In Abschnitt 8.3. “Abbildung von Codelisten” wurde die Tabelle 8.3. “Metadaten einer Codeliste” redaktionell überarbeitet. (CR 528)

Der Leitfaden zur Bildung von Uniform Resource Names (Abschnitt 8.4.1.) wurde überarbeitet. (CR 441)

Das XÖV-Glossar (Anhang B) wurde um den Begriff “XÖV-Starterpaket” erweitert. (CR 390)

In Abbildung 7.3. “Beziehungen zu den Eigenschaften einer XÖV-Kernkomponente” wurde der Stereotyp “xoevASBIE” an der Assoziation zwischen den Bausteinen “Anschrift” und “KodierungVerwaltungspolitisch” entfernt. (CR 479)

Der Abschnitt 2.5. “Änderungsmanagement” wurde um einen Verweis auf die XÖV-Webseite zur Übersicht der XÖV-Releases erweitert. (CR 529)

Darüber hinaus wurden redaktionelle Korrketuren vorgenommen. (CR 516)

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

CR 2011-204: Anpassung des XÖV-Konformitätskriteriums K-4 (Veröffentlichung):: Die Regel wurde bzgl. des Ablaufs angepasst. Die Veröffentlichung eines Standards im XRepository ist keine Vorbedingung mehr, statt dessen muss die Veröffentlichung unverzüglich nach der Zertifizierung erfolgen. CR 2011-09-06-1: Änderung am Codelistenformat (Genericode):: Die Kennzeichnung einer Spalte der Codelisten-Repräsentation als 'codename' (gemäß XÖV-Basisdatentyp Code, Attribut "name") wurde entfernt. Grund: In der Praxis der Darstellung von Codelisten hat sich diese Einschränkung als hinderlich erwiesen. Codelisten sind rationeller darstellbar und vielseitiger einsetzbar, wenn man solche Festlegungen dem User (Einsatz der Codeliste im XÖV-Standard oder in einer Applikation) überlässt. CR 2010-011: Aufnahme weiterer Zeichen in String.Latin und Veröffentlichung eines Standards "Lateinische Zeichen in Unicode":: Der Datentyp String.Latin wird zukünftig durch einen eigenständigen Standard “Lateinische Zeichen in Unicode” (verfügbar unter xoev.de/latinchars/) beschrieben. Dieser Standard beschreibt den Zeichensatz der lateinischen Zeichen sowie den entsprechenden Datentyp String.Latin in XML Schema und UML. Gegenüber der in der Version 1.0 des XÖV-Handbuchs veröffentlichten Fassung von String.Latin wurden Zeichen ergänzt. Für die inhaltlichen Änderungen wird auf den genannten Standard verwiesen. CR 2010-013 / CR 2011-06-16-6: Unterstützung zusätzlicher Eigenschaften bei Wildcard Elementen:: Der Stereotyp xsdAnyContents unterstützt nun die Angabe der Häufigkeiten (minOccurs, maxOccurs) und die Art der Inhaltsverarbeitung (processContents). CR 2011-06-16-4: Modellierung von Unions:: Mit Hilfe des Stereotypen xsdUnion können jetzt xs:union Datentypen modelliert werden. CR 2011-06-17-1: Restriction base bei Enumerations:: Für Enumerationen im Schema kann ein beliebiger einfacher Typ als Basistyp angegeben werden. CR 2011-06-16-3: Globale Elemente mit Choice:: Globale Elemente können als Inhaltsmodell nun auch einen Choice haben. CR 2011-06-16-2: Referenzierung von globalen Elementen, Element- und Attributgruppen:: Die Referenzierung von globalen Elementen, Element- und Attributgruppen ist jetzt möglich. CR 2011-06-16-1: Typisierte globale Elemente:: Globale Elemente können anhand eines komplexen Typen definiert werden. CR 2011-06-17-2: Element- und Attributgruppen:: Element- und Attributgruppen können definiert werden. CR 2011-05-20-1: Änderung der Angaben zum XMI-Formats des XGenerators:: Der XGenerator liest ab der Version 2.2.0 nur noch XMI-Dateien in der Version 2.x und keine 1.X Dateien mehr. CR 2010-102, 2010-103, 2010-10-01-1: Dokumentation von neuen Elementen für die Dokumentationsgenerierung:: Das XOEV-Profil wurde um verschiedene Elemente erweitert, die bei der Dokumentationsgenerierung berücksichtigt werden können. Dabei handelt es sich um neue Stereotypen (xsdDeprecated, xsdXModelImport) und neue Eigenschaften von Stereotypen (xsdCode.documentationCodeList) CR 2011-09-06-1: Entfernen der Invarianten:: Die technische Umsetzung der Namens- und Entwurfsregeln durch Invarianten wird im Handbuch nicht mehr im Detail beschrieben.