bonjour
c'est un bon sujet !
j'ai utilisé avec succès isomorphe pour passer les transformations de compatibilité data.gouv
puis je l'ai installé en local / docker pour en ajouter d'autres, avec succès aussi
l'application est vraiment très simple, beaucoup plus simple que la moindre des opérations XSL du GUI geonetwork. les gros avantages :
* pour une plateforme partenariale, la découverte des données par groupe geonetwork/organisation est bien pensée
* un diff est présenté avant écriture, c'est rassurant
* les transformations de base sont bien faites et constituent une ressource documentée très utile
pour moi l'application est satisfaisante dans son état actuel et la bibliothèque partagée de xsl a tout son sens. elle pourrait effectivement être + intégrée à georchestra pour l'authentification et le bandeau, mais :
* une fois les fiches mises en conformité, on y revient pas, ou alors à la marge => le dev complémentaire est-il rentable ?
* isomorphe a l'avantage de fonctionner pour tous les catalogues geonetwork, pas que georchestra => ça répond à des situations mixtes
les bénéfices d'avoir sa propre instance isomorphe seraient la confiance et l'ajout de xsl locaux. je serais tenté d'avoir isomorphe en local, mais en évitant vraiment le fork. à savoir, une contrib à isomorphe pour avoir une compo complète et opérationnelle (c'est quasi fait), avec un point de montage pour les xsl locaux. et on fait l'impasse sur le header. pour les install non docker ça se fait bien aussi.
dans certains cas comme celui de rennes, le catalogue n'est pas accessible depuis l'extérieur, et l'instance locale prend tout son sens.
l'autre option est de coopérer avec le projet pour leur demander d'ajouter les xsl d'intérêt général qu'on aurait rédigées, et ça marche (ajout récent de la normalisation des getcapabilities ogc).