FIT-Connect-SDK - Java: XML-Validierung in Version 2.5.0 per Default eingeschaltet und fehlerhaft

Einem unserer mitnutzenden Ländern ist eine Änderung des Verhaltens des FIT-Connect-SDK 2.5.0 aufgefallen, die einen Breaking Change darstellt. Der EfA-Onlinedienst aus Sachsen-Anhalt sendet die Antragsdaten in einem FIM-basierten XML-Format an FIT-Connect und nutzt dafür eine URN als SchemaUri, die durch das FIM-Werkzeug ARIS generiert wird. Es handelt sich also nicht um ein XÖV-Schema. Beim abrufenden Fachverfahren des mitnutzenden Landes tritt mit Version 2.5.0 nun dieser Fehler auf:

Requesting XML schemas from https://www.xrepository.de/api/version_standard/urn:xoev-de:xfall:standard:fim-s17000725_2.1/xmlschema Received response 404 for GET on https://www.xrepository.de/api/version_standard/urn:xoev-de:xfall:standard:fim-s17000725_2.1/xmlschema

Das ist leider erwartbar, denn das neue Verhalten des SDK ist nun so, dass die URN des Schemas zwingend auf ein XÖV-Schema im XRepository zeigen muss, welches dann als ZIP-Datei heruntergeladen wird. Unabhängig von der Caching-Problematik, die am entsprechenden Epic (https://git.fitko.de/fit-connect/planning/-/issues/1151) diskutiert wird, sollte dies nicht das Standardverhalten sein. Ein XML-Schema muss nicht zwingend im XRepository vorhanden sein. Es kann auch im FIM-Sammelrepository existieren oder auch nur als Datei vorliegen. Die entsprechende JSON-Implementierung berücksichtigt sowohl ein Caching als auch die Möglichkeit, Schemadateien als Datei abzulegen und darauf zu verweisen. Die Umsetzung widerspricht auch dem Akzeptanzkriterium Nr. 1 des Epics:

In der 1. Iteration werden die SDKs die Schematas auf Anfrage laden, um dagegen zu validieren.

Die Schematas werden in der aktuellen Implementierung nicht auf Anfrage geladen, sondern per Default. Das Feature sollte unserer Meinung nach als experimentell gekennzeichnet und explizit aktiviert werden müssen.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information