fxprunayre
commented
5 years ago Réponse ici aux différents tickets sur le sujet de la validation:
Namespaces
Quelles règles/bonnes pratiques suivrent dans la déclaration des namespaces pour être conforme INSPIRE? Le TG metadata signale notamment l'utilisation de
Dans la pratique, c'est purement cosmétique de vouloir utiliser tel ou tel préfix et de positionner les namespaces en haut du document. L'outil informatique s'en fout :) On peut mapper http://www.isotc211.org/2005/gco sur titi et ça fonctionnera bien. Après il est même difficile de forcer ces choses là (en XSL en tout cas) - c'est pas impossible mais des choses comme l'utilisation des Xlinks avec les annuaires conduisent à l'injection de fragments dans des documents existant. Si on veut vraiment mettre tout ça cosmétiquement nickel, il faudrait ajouter une étape lors de la sauvegarde qui fait ce ménage. A voir, si c'est vraiment nécessaire ?
Validation par rapport au schéma
- Se base sur le XSD
- Le(s) XSD à utiliser est: a) soit indiqué dans l'en tête du XML xsi:schemaLocation b) soit défini par l'outil qui fait la validation (qui peut éventuellement décider d'ignorer le xsi:schemaLocation)
Dans GeoNetwork, dans le XML il est préconisé de ne pas mettre de xsi:schemaLocation voire même de l'ignorer cf. l'admin:
Exemple de pb: Dans la pratique vous importez une fiche ayant un xsi:schemaLocation ne pointant pas vers gmx/gcx (pour les Anchor), vous décidez d'utiliser les Anchors dans la fiche importée, le XSD référencé retournera des erreurs.
Un schéma dans GeoNetwork définit quel schemaLocation utiliser (eg. iso19139 https://github.com/SPW-DIG/metawal-core-geonetwork/blob/metawal-3.4.x/schemas/iso19139/src/main/plugin/iso19139/schema-ident.xml#L68-L71, 19115-3 https://github.com/metadata101/iso19115-3/blob/3.4.x/src/main/plugin/iso19115-3/schema-ident.xml#L55 à vérifier). Cet élément est ajouté lors d'un export XML.
INSPIRE
Il nous faut déjà définir ce que vise Metawal: TG1.3 ou TG2 (et quel validateur on utilise l'ancien ou le nouveau).
Actuellement GeoNetwork supporte TG1.3.
Pour TG2, ça nécessite:
- Import depuis Registry INSPIRE (fait)
- Utilisation des Anchors pour un certain nombre d'éléments (partiel)
- Adapter l'encodage de champs tels que CRS, operatesOn qui ont changé
- Créer un schématron TG2 pour pouvoir valider dans GeoNetwork
- Créer un XSL de transformation TG1.3 > TG2 pour automatiser au maximum les choses.
En fonction de l'objectif, on définit la liste des choses à faire et pour quand? A discuter
TODO:
- [ ] ISO19115-3 / Vérifier quel xsi:schemaLocation utiliser
- [x] ISO19115-3 / Lors de la conversion 19139, ajouter un schemaLocation ?
- [x] ISO19115-3 / Validateur INSPIRE / Convertir en 19139 avant de valider
- [ ] Fiches existantes / Supprimer les xsi:schemaLocation
- [ ] INSPIRE ... à préciser
- [ ] Namespace / Cosmétique ?
Ce ticket-question est destiné à clarifier la manière dont sont référencés les namespaces dans les fiches de MD, et la manière dont on les fait évoluer.
Il est en lien avec les erreurs constatées par le validateur INSPIRE (sandbox) rapportées dans #434
Au niveau des fiches de MW3 (env. prod), il y a un manque d'homogéneité dans la déclaration des namespaces et des schemaLocation associés.
Les questions sont apparues suite au fait que :
L'analyse des namespaces référencés dans MW3 montrent une diversité de déclaration. Ex:
PICC : http://metawal.wallonie.be/geonetwork/srv/fre/search?uuid=b795de68-726c-4bdf-a62a-a42686aa5b6f. Plusieurs namespaces - pas de déclaration du gmx - cas classique qui fait qu'on doit étendre la déclaration pour être conforme
INSPIRE - site protégés Natura 2000 - http://metawal.wallonie.be/geonetwork/srv/fre/search?uuid=541e92de-dbc9-46df-880c-1076798bdbb3. Plusieurs namespaces différents. Ca passe au validateur mais une validation locale montre que des schémas se font concurrences
xmlns:gmd="http://www.isotc211.org/2005/gmd" xmlns:gts="http://www.isotc211.org/2005/gts" xmlns:gco="http://www.isotc211.org/2005/gco" xmlns:ogc="http://www.opengis.net/ogc" xmlns:gmx="http://www.isotc211.org/2005/gmx" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:gml="http://www.opengis.net/gml" xmlns:geonet="http://www.fao.org/geonetwork" xsi:schemaLocation="http://www.isotc211.org/2005/gmd http://www.isotc211.org/2005/gmd/gmd.xsd http://www.isotc211.org/2005/gmx http://www.isotc211.org/2005/gmx/gmx.xsd http://www.isotc211.org/2005/srv http://schemas.opengis.net/iso/19139/20060504/srv/srv.xsd"xmlns:gco="http://www.isotc211.org/2005/gco" xmlns:gmx="http://www.isotc211.org/2005/gmx" xmlns:ogc="http://www.opengis.net/ogc" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:gts="http://www.isotc211.org/2005/gts" xmlns:gml="http://www.opengis.net/gml" xmlns:gmd="http://www.isotc211.org/2005/gmd" xsi:schemaLocation="http://www.isotc211.org/2005/gmd http://www.isotc211.org/2005/gmd/gmd.xsd http://www.isotc211.org/2005/gmx http://www.isotc211.org/2005/gmx/gmx.xsd"A plusieurs endroits des XML, on re-référence des namespaces qui sont déclarés de manière globale, ce qui n'est pas utile mais n'entraine pas d'incompatibilité
Question
Quelles règles/bonnes pratiques suivrent dans la déclaration des namespaces pour être conforme INSPIRE? Le TG metadata signale notamment l'utilisation de
Mais il n'y a pas d'exemple type fourni
Suite à la migration, comme envisager la gestion du passif? Comment procéder aux mises à jour éventuelles et parvenir à intégrer de manière générique les schémas permettant notamment la prise en compte des ancres, ou d'adapter les fiches pour garantir la bonne conformité vis-à-vis d'INSPIRE?
Des transformations peuvent elles être implémentées automatiquement lors du passage à MW4? Si oui, elles doivent être envisagées dès maintenant.
Des opérations manuelles sur les fiches en ISO 19115-3 devront elles être réalisées pour arriver à une homogénéité dans les déclarations de schéma.