Bunge/cit: Prüfung auf leere Elemente mit XML-Schema-Mitteln

XBAU-465
Umsetzung
Di., 03.03.2026 - 14:24
 
Di., 10.02.2026 - 11:32
priority-icon Medium

In Ticket [Databund: leere Elemente mit Datentyp String.Latin | XLeitstelle|https://xleitstelle.de/jira/XBau/tickets/XBAU-178] wurde bereits das Problem thematisiert, dass für Freitextinhalte Datentypen verwendet werden, die auch leere Inhalte zulassen.

Der genannte CR wurde gelöst, indem eine generische Schematron-Regel bereitgestellt wurde, die auf leere Elemente prüft.

Es gibt jedoch verschiedene Konstellationen, in denen die Einschränkung des Inhaltes auf Ebene von XML-Schema vorteilhafter ist.

Aus diesem Grunde wird vorgeschlagen, einen Datentyp von DatatypeC abzuleiten, der folgende Einschränkung hat:

  • minLength = 1
  • whiteSpace = collapse (Whitespace wie z.B. Leerzeichen an Anfang und Ende des Textes entfernen, aufeinanderfolgenden Whitespace zusammenfassen)

Dadurch muss der Inhalt immer aus mindestens einem nichtleeren Zeichen bestehen.

Optional kann über die Definition einer Maximallänge diskutiert werden.

Kommentare

EG26-01 25.02.2026

  1. Grundsatzentscheidung zu treffen über die Semantik generell leerer Text-Elemente (Vorschlag: wie XInneres bzw. XMeld). Ergebnis: leere Text-Elemente sind nicht spezifikationskonform (gilt für Leerstring und whiteSpace; gilt für optionale wie auch mandatorische Elemente). Text-Elemente müssen, damit die XBau-Nachrichteninstanz spezifikationskonform ist, informativen Inhalt haben.
  2. Bewertung aktueller Mechanismus der Prüfung per Schematron. Ergebnis: Ist nur ein Mittel, Sichtbarkeit zu schaffen.
  3. weitergehende Maßnahmen, Ergebnis: Die Regelungen sollen per XSD realisiert werden. Ansatz wäre, wie im voriegenden CR formuliert, einen Datentyp von DatatypeC abzuleiten mit den Einschränkung <minLength = 1> und <whiteSpace = collapse (Whitespace wie z.B. Leerzeichen an Anfang und Ende des Textes entfernen, aufeinanderfolgenden Whitespace zusammenfassen)

Es wird gesehen, dass so informativer Text nicht erzwungen werden kann, das Thema bekommt aber - auf der Ebenen XBau-Regeln - einen stärkeren Fokus.

Das Meinungsbild ist eindeutig unterstützend für diese Lösung im Sinne des Antragstellers. Soll umgesetzt und durch technische Tests abgesichert werden. Dann Wiedervorlage im EG.

Das Thema maxLength soll weiter diskutiert werden.

Es besteht noch keine Klarheit, inwieweit der Text in einem Anschreiben (z.B. Nachricht prozessnachrichten.fachlicheKommunikation.1142/anschreiben) eingeschränkt werden sollte. Auf Ebene Antragsportal möchte man den User nicht unnötig gängeln. Andererseits werden die IT-Verfahren der Fachbehörden vor Herausforderungen gestellt (müssen sich auf Länge = beliebig einstellen)

Status in Arbeit

Anmerkung:

MinLength → in Umsetzung
MaxLength → Besprechung im nächsten EG