Ich stelle mir die Entwicklung solcher Funktionen, die die Geometrie betreffen, aufwändiger vor als solche, die bereits bestehende Java-Funktionen nachbilden (concat, trim, sum usw.).
Wie du könnte ich mir aber auch ein offizielles Modell vorstellen, das sukzessive mit Geometrie-Funktionen ergänzt wird (resp. das Modell sollte einmal einen Grundstock von geometrischen Funktionsdefinitionen festlegen und diese werden - bei Bedarf - entwickelt).
Die geow-Bibliothek wurde schon mit dieser Idee ins Leben gerufen, dass sie mal als offizielle Bibliothek weiterlebt und immer umfangreicher wird.
Mich persönlich überzeugt das Konzept, dass diese Funktionen in einer externen Bibliothek untergebracht sind und diese so im Bedarfsfall unabhängig vom ilivalidator unkompliziert erweitert (und implementiert) werden kann.
Externe Bibliotheken verwenden ist halt so ne Sache. Muss man auch wieder verstehen. Ein geniales Meccano fehlt m.E. noch. Der Benutzer muss den Artefakt selber herunterladen. Wo muss er ihn herunterladen? Standard-Geometrie-Funktionen gehören für mich in den Kern eines Validators. Bei 2-3 Releases pro Jahr dünkt mich das auch kein Problem. Man muss nicht immer alles trennen. Spezial-Geometrie-Funktionen sind dann wieder eine andere Sache. Aber doch nicht GetLength oder GetArea.
Das verstehe und teile ich grundsätzlich. Die Schwierigkeit ist wohl die der Abgrenzung (das zeigt ja auch die heutige Situation). Wir sind zum Beispiel aktuell an einer Zusatzfunktion für einen Kunden dran, die prüft, ob eine Polyline komplett oder teilweise auf einer anderen Polyline liegt. Ist das beispielsweise schon eine Spezial-Geometrie-Funktion oder noch Standard?
Den Aspekt bzgl. der Plugin-Implementierung kann m.E. mit Dokumentation problemlos gelöst werden. Dafür ist man dann nicht an einen spezifischen Validator-Release gebunden und ist flexibler.
Ich glaube die Herausforderung ist tatsächlich wie man mit möglichst atomaren Funktionen möglichst viel abdecken kann. Spontan könnte man auch sagen: siehe PostGIS (bezüglich Funktionen). Die Diskussion müsste man mindestens bei den Text-Funktionen auch führen. Dort ist es kein Thema.
Beim Plugin-Mechanismus kommt noch hinzu, dass du hier ggf in Konflikte bezüglich Lib-Versionen gerätst. Mich dünkt, so gut und richtig die Argumentation ist wegen Flexibilität, es hindert den Benutzer und hilft dem Entwickler irgendwie auch nicht.