Interlis leicht gemacht #15

Im letzten Beitrag zeigte ich wie man in ilivalidator eigene, zusätzliche Constraints definieren kann und eigene Java-Funktionen schreiben kann. Beides hat zum Ziel, dass man neben der eigentlichen Modellprüfung zusätzliche Prüfungen durchführen kann. Von der Version 0.10.0 zur Version 1.0.0 hat sich da noch einiges getan. Und eines vorweg: es ist ziemlich genial geworden.

Ich habe den fast gleichen Test-Rumspiel-Datensatz wie beim letzten Mal verwendet (ein paar Fixpunkte). Einzig den Modellnamen habe ich leicht angepasst: AVLight. Das Modell sieht jetzt so aus:

Wenn ich jetzt einen «no-frills» ilivalidator-Aufruf mache, meldet es mir bereits einen Fehler. Eine Höhe ist viel zu gross und entspricht nicht den Vorgaben des Modelles.

Wenn ich nun weiss, dass die Nummern der Fixpunkte bei uns immer nur acht Zeichen lang sind, kann/muss ich einen zusätzlichen Contraint definieren. Beim letzten Mal habe ich diesen Contraint mit der vordefinierten INTERLIS-Funktion INTERLIS.len() direkt in das Original-Modell geschrieben. Das geht natürlich, ist aber nicht sonderlich elegant und man müsste immer so etwas wie eine Schattenkopie des wirklichen Originals vorliegen haben.

Eleganter geht es mit Views. INTERLIS-Views sind mir soweit gänzlich unbekannt und die Syntax auch nicht nicht wirklich geläuft, aber für etwas gibt es ja das Referenzhandbuch und die ilivalidator-Dokumentation. Man schreibt sich jetzt also ein AVLight_Check-Modell und definiert dort die Views mit den zusätzlichen Constraints:

Um die Prüfung mit dem zusätzlichen Constraint durchzuführen, braucht es einzig noch einen Eintrag in der Konfigurationsdatei AVLight.toml:

So wird ilivalidator mitgeteilt, dass es ein weiteres zu berücksichtigendes Modell gibt. Der Aufruf erfolgt mit dem --config-Parameter und liefert folgenden zusätzlichen Fehler:

Schön. Nur nicht sonderlich leserlich. Mit Metattributen !!@…​ (Zeilen 14 und 15) kann man nun einerseits den Constraint mit einem Namen versehen und auch eine für den Menschen lesbare Fehlermeldung ausgeben:

Die Metattribute müssen vor den betroffenen Constraint platziert werden. Das Ergebnis ist definitiv informativer:

Wenn ich jetzt Dinge prüfen will, die ich nicht mehr mit den INTERLIS-Standardfunktion umsetzen kann, muss ich selber in die Java-Tasten hauen. Grundsätzlich gilt weiterhin, dass man ein Java-Interface implementieren muss. Bei uns beginnen alle BfS-Nummern mit einer «2». Jetzt kann ich also eine «SubText»-Funktion schreiben, die von einem String einen Teil extrahiert und mit einer «2» vergleicht und das Ganze in einen MandatoryConstraint packen:

Disclamer: Die Methode habe ich gewählt, weil sie bereits aus Testzwecken im iox-ili-Code vorhanden ist.

Neu müssen die - nennen wir sie mal - Custom Functions eine Methode getQualifiedIliName() implementieren. Der Rückgabewert ist ein qualifizierter Name, wie man die Methode in Modellen ansprechen kann. Dafür fällt in der Deklaration im Modell das Metaattribut weg. Zuerst sah ich die Eleganz nicht und dachte, dass man ja jetzt gleiche Methoden für verschiedene Modelle schreiben muss. Aber weit gefehlt. Als man es mir dann erklärte, dämmerte es: Man (z.B. eine Organisation, ein Checkservice-Anbieter) erstellt für die Deklaration der Methoden ein eigenes INTERLIS-Modell, das man - analog wie das AVLight-Modell - jeweils in das Check-Modell importiert. Daher ist der qualifizierte Name meiner Implementierung der SubText-Methode SO_FunctionsExt.mySubText. SO_FunctionsExt ist das Modell in dem einzig meine Funktion deklariert wird.

Die Methode wird jetzt kompiliert und als JAR-Datei in einen Ordner kopiert. Standardmässig lädt ilivalidator seit Version 1.0.0 die Custom Functions aus dem plugins-Verzeichnis (muss erstellt werden) innerhalb der Applikation. Dies kann aber mit dem Parameter --plugins übersteuert werden. Bei mir hat das Laden meiner SubText-Funktion nicht auf Anhieb funktioniert. Ich habe das Gefühl, dass im iox-ili-Code noch ein Fehler versteckt ist. Erst eine zusätzliche Zeile und das anschliessende Kompilieren von iox-ili und kopieren der Bibliothek in das libs-Verzeichnis von ilivalidator hat die Custom Functions gefunden (resp. eben die Klasse geladen).

Anschliessend muss ich das erwähnte SO_FunctionsExt-Modell erstellen:

Ebenfalls leicht anpassen muss ich das AVLight_Check-Modell:

In Zeile 6 wird das «Funktions-Deklarations-Modell» importiert. Damit hat sich es erledigt. Natürlich muss man noch den Constraint selber ausformulieren und falls gewünscht die passende Fehlermeldung dazu (Zeilen 19 - 21).

Der ilivalidator-Aufruf liefert korrekterweise einen Fehler:

Um eigene Bedingungen zu formulieren mit oder ohne eigenen Tests muss ich in erster Linie nichts Anderes verstehen als INTERLIS. Keine zusätzliche INTERLIS-Validierungssyntax oder ähnliches. Ich brauche keinen neuen Skriptsyntaxparser/-validator, denn den gibt es ja bereits: den INTERLIS-Compiler. Klar, will ich eigene Funktionen schreiben, muss man ein wenig Java beherrschen. Aber that’s it. Die Verwaltung der zusätzlichen Check-Modelle? Gelöst, nennt sich INTERLIS-Modellablage und hat sich etabliert.

Sämtliche Daten finden sich hier. Das Git-Repo mit meiner Custom Function gibt es hier.