Ankündigung: Neufassung der Namenskomponenten

Notwendigkeit und Zielsetzung der Neufassung

Die folgenden Aspekte haben zu der Entscheidung geführt, trotz des damit verbundenen Aufwandes die zentrale Datenstruktur NameNatürlichePerson und die damit unmittelbar zusammenhängenden Datenstrukturen neu zu modellieren:

• Stärkere Ausdrucksmächtigkeit

  In den einschlägigen Rechtsgrundlagen zur Übermittlung von Meldedaten werden bezüglich der Übermittlung von Namen oder Namenskomponenten häufig Einschränkungen vorgenommen. In bestimmten Situationen wird beispielsweise festgelegt, dass nur der aktuelle Familienname und der aktuelle Vorname übermittelt werden dürfen. Dementsprechend dürften in diesem Beispiel die früheren Namen oder der Geburtsname des Betroffenen nicht übermittelt werden.

  Mit der bisher vorhandenen Namensstruktur kann eine solche Einschränkung lediglich verbal gefordert werden. Wir verfügen nicht über die Möglichkeit, die Einhaltung dieser Einschränkung mit den Mitteln von XML Schema auszudrücken. Hierfür wäre ein Sprachkonstrukt erforderlich, welches ausdrücken würde: „In dem übermittelten Element nachname muss dass Attribut rolle den Wert FN besitzen.“ Dies ist mit den Mitteln von XML Schema nicht möglich. Validierende Parser würden nicht prüfen können, ob diese Bedingung eingehalten wird.

  Ein Ziel der Neufassung bestand darin, dass zukünftig mit den Mitteln von XML Schema präziser ausgedrückt werden kann, welche Namenskomponenten in einer Nachricht zugelassen sind.

• Reduktion der Komplexität

  Die bisher vorhandene Namensstruktur und ihre Komponenten (Vorname, Nachame) waren aus Sicht der Implementierung komplexer als andere Datentypen, da einige Randbedingungen zu beachten waren, die nicht mit den Mitteln von XML Schema ausgedrückt werden können und daher in der programmiertechnischen Umsetzung als zusätzliche Anwendungslogik notwendig waren. Zu diesen Rahmenbedingungen gehören unter anderem:

  • In einem Namen darf es zwar mehrere Nachnamen geben, aber stets maximal eines der Elemente darf in einer der rollen „Geburtsname“ oder „Ehename“ oder „Lebenspartnerschaftsname“ oder „(aktueller) Familienname“ auftreten.

  • Es darf mehrere Vornamen geben, aber diese müssen korrekt durchnummeriert sein. Es darf keine zwei Elemente mit der gleichen rolle geben, die die gleiche laufendeNr haben.

  Darüber hinaus gab es keine „einfache“ Methode um festzustellen, ob z. B. ein aktueller Familiennamen als Bestandteil eines Namens übermittelt worden ist. Hierfür war die Liste aller Nachnamen darufhin zu überprüfen, ob einer (und nur einer) die rolle „FN“ besaß.

  Ein Ziel der Neufassung bestand darin, die mit dem Namen verbundenen Datenstrukturen in ihrer Komplexität zu reduzieren und damit „einfachere“ Implementierungen zu erlauben – auch wenn es aus der Sicht der OSCI XMeld-Modellierung sicherlich nicht immer eindeutig zu beurteilen ist, wie sich die Situation aus Sicht der Entwickler darstellt.

• Stärkere Nähe zu DSMeld

  In der bisherigen Datenstruktur nameNatuerlichePerson konnte auf Grund des Rollenkonzeptes nur in allgemeiner Form angegeben werden, dass ein Name aus mehrere Nachnamen bestehen kann, die in verschiedenen Rollen auftreten können. Die möglichen Rollen sind im DSMeld definiert.

  Ein Ziel der Neufassung bestand darin, innerhalb der Struktur nameNatuerlichePerson die Elemente einzufügen, die einen unmittelbaren Bezug zum MRRG und zum DSMeld haben (zum Beispiel ehename, geburtsname und so weiter.

Wesentliche Unterschiede zwischen bisheriger und neuer Modellierung

Um die in Abschnitt namens Notwendigkeit und Zielsetzung der Neufassung dargestellten Ziele erreichen zu können, wurden folgende wesentliche Veränderungen in den hier betrachteten Datenstrukturen vorgenommen:

Beispiele für die neuen Namenskomponenten

Die folgenden Beispiele sollen die Nutzung der neuen Namenskomponenten erläutern.