Handlungsanweisung zu "XBau-Anhänge & XTA-Container"
High
- Kernmodul
Governikus: "Uns ist aufgefallen, dass die XML-Datentypen der dokumentid (XBau-Kernmodul MetadatenAnhang) und die XTA-Attachment-ID (Metadaten im ContentContainer) nicht zusammenpassen.
In xs:anyURI (dokumentid) sind mehr Zeichen erlaubt als in xs:IDs (XTA-Attachment-ID bzw. ContentType/@id).
In unserer Implementierung sind wir jetzt davon ausgegangen, dass in einer documentid nur Zeichen verwendet werden, die in XSD-ID erlaubt sind.
Zusätzlich wäre es hilfreich, wenn neben der ID-Präzisierung auch die Übertragung des Filenames explizit im Transport-Profil beschrieben wird.
Kommentare
Technische Details den unter Punkt 1) verwendeten beiden Datentypen:
xs:ID ist ein Legacy-Typ (nämlich eine Nachahmung des DTD-Typs ID). Er ist im XDM (dem Datenmodell, das XML Schema zugrunde liegt) eine Spezialisierung des abgeleiteten einfachen Typs xs:NCName, der seinerseits xs:token spezialisiert: Seine Facette xs:whitespace hat also den Wert "collapse" (d. h. es wird vorne und hinten Weißraum wie Leerzeichen, Tabs etc. abgeschnitten). Deshalb darf - in ebendieser Weise weißraumnormalisiert - in einer xs:ID kein Leerzeichen enthalten sein (sprich: "a a" ist ungültig, aber " aa " wird wie "aa" behandelt und ist gültig). Generell gilt: Da ja jede xs:ID ein xs:NCName (= non-colonized Name, also ein doppelpunktloser Bezeichner ohne Namespace-Präfix) ist, muss diese zwingend mit einem Buchstaben oder einem Unterstrich ("_") beginnen - eine Ziffer als erstes Zeichen ist nicht valide - und darf ausschließlich Buchstaben, Ziffern, Unterstriche, Bindestriche ("-") und Punkte ("."), aber insbesondere keine Doppelpunkte (":") enthalten (vgl. zur Veranschaulichung der Zusammenhänge die Übersicht der Typenhierarchie - hier eine veraltete Fassung, weil die aktuellste Darstellung den betrachteten Sachverhalt meines Erachtens weniger zugänglich zeigt.). Eine xs:ID darf zudem nicht die leere Menge ("") sein, und sie muss einmalig 
sein pro Dokument: Semantisch ist sie keine Referenz, sondern ein innerhalb der Dokumentgrenze eindeutiger Identifikator.
Ein xs:anyURI ist hingegen selbst ein atomarer Ur-Typ (der atomare Ur-Typ zu xs:ID ist xs:string): Er kann beliebig oft pro Dokument vorkommen (semantisch ist er nicht Identifikator, sondern surjektive Referenz auf einen (typischerweise auf eine externe Entität zeigenden) Identifikator); als Gedankenbrücke kann man sich eine 'Internetadresse' (https://init.de) vorstellen (selbst wenn das aber eine URL ist, kein URI), die beliebig oft vorkommen kann und stets auf ein und dieselbe Ressource zeigt. Der logische Werteraum eines xs:anyURI enthält alle URIs, wie sie in den RFCs 2396 und 2732 definiert werden, d.h. der lexikalische Raum (welche serialisierten Zeichen konkret zulässig sind) von xs:anyURI ist größer als der einer xs:ID: Ein xs:anyURI darf Leerzeichen enthalten (die aber escaped werden sollten, also als "%20" geschrieben; vgl. besagte RFC 2396). Technisch gesehen darf er auch die leere Menge sein, kann zudem mit einer Ziffer beginnen, darf Slashes ("/"), den Doppelpunkt (":") und diverse andere Sonderzeichen enthalten. Eine Sonderrolle hat die Raute, die als local fragment identifiert ("Anker") dient und deshalb pro xs:anyURI nur genau einmal vorkommen darf.
TL;DR: In xs:IDs sind nur Buchstaben, Ziffern, Unter- und Bindestriche sowie Punkte erlaubt, während für xs:anyURIs der lexikalische Werteraum größer ist. Ihre Semantik unterscheidet sich außerdem (Identifikator vs. Referenz), wodurch sich unterschiedliche Regeln ergeben, was genau (nicht) vorne stehen und wie oft vorkommen darf.
Bemerkung cit:
Gehen Sie mit, dass eine solche Handlungsanweisung jetzt benötigt wird?
Unbedingt, sonst bekommen wir ggf. Probleme in der Produktion und wir brauchen hier eine zentrale Festlegung. Das Problem entsteht, dass wir eine eindeutige technische ID zwischen Metadaten innerhalb eines Fachdatensatzes und den angehängten Attachments benötigen. Hier müssen die genutzten Wertebereiche kompatibel zum genutzten Transport bzw. Interface sein (also letztlich dann eine Einschränkung auf xs:ID)
Entwurf HA zu XBau 2.3.1 liegt vor, im GitLab-Ordner \spezifikation\Ergänzungen\Handlungsanweisungen
Wäre jetzt zu finalisieren und zu veröffentlichen.
Die Entwürfe für 2.3 und 2.3.1 wurden bearbeitet und können jetzt in die QS.
Handlungsbedarf zu den beiden Punkten:
1) Datentyp Element dokumentid (in xbauk:MetadatenAnhang) --> mappt vom Datentyp her (Scope zugelassene Zeichen) nicht auf den Datentyp des Attributs id aus dem XTA-Content-Type) - es geht um die XSD-Datentypen xs:anyURI (viele verschiedene Zeichen erlaubt) und xs:ID (weniger Zeichen erlaubt)
Abbildungen: XBau-Datentyp; zu XTA aus Anhang C der Spezifikation Kernmodul 1.2
2) Im Anhang C der Spezifikation von Kernmodul 1.2 wird zum Mapping des oben genannten Elements (dokumentid) auf XTA und OSCI ausreichend präzise Angaben gemacht. Nicht zum ebenfalls relevanten Element dateiname (siehe Abb unten).