Conformité et extensions¶
Afin de maximiser l'interopérabilité des données publiées en utilisant le standard OCDS, nous avons établi des principes clés pour être en conformité avec le standard. Il est ainsi possible de créer des extensions du standard grâce auxquelles les producteurs de données peuvent répondre à des besoins d'utilisateurs particuliers.
Conformité¶
Conformité de la publication des données¶
Une implémentation conforme au standard peut n'utiliser qu'un sous-ensemble des termes de cette spécification.
Elle ne doit pas utiliser des termes extérieurs à ces spécifications lorsque les termes de ces spécifications suffisent.
Son utilisation des termes de cette spécification doit être compatible avec la sémantique de ces termes.
Elle peut utiliser des termes extérieurs aux termes de ces spécifications lorsque les termes de ces spécifications sont insuffisants.
Si une implémentation du standard produit des données au format JSON, ces données doivent être en conformité avec le schéma JSON correspondant à ces spécifications.
Chaque fois que vous utilisez des termes en dehors de la norme OCDS, nous encourageons le producteur ou l'utilisateur responsable à consulter la communauté sur la meilleure approche à adopter.
(Our publication conformance section is based on the Popolo Project approach.)
Validateur et conformité des applications¶
À partir d'OCDS 1.1, les packages d'instances et d'archives devraient inclure un champ 'version' pour déclarer explicitement leur version d'OCDS. Tous les packages sans une version explicitement déclarée devraient être validés par rapport au schéma de la version 1.0, sauf indication contraire de l'utilisateur.
Les validateurs et les applications devraient :
Signaler à l'utilisateur lorsqu'il rencontre une version des données qu'il ne supporte pas ;
Rejeter les données d'une version d'un entier supérieure à celle qu'elle prend en charge, sauf indication contraire de l'utilisateur ;
Signaler à l'utilisateur lorsqu'il rencontre des extensions qu'il ne supporte pas ;
Les outils de validation doivent avertir l'utilisateur lorsqu'ils rencontrent des champs non couverts par la version du schéma et des extensions par rapport auxquels ils valident.
Les applications peuvent émettre un avertissement lorsqu'elles rencontrent des champs non-supportés, ou bien elles peuvent ignorer ces champs.
La gestion des champs supplémentaires et des champs dépréciées est propre à chaque implémentation.
Pour les comportements propres à l'implémentation choisie par le développeur, les applications devraient clairement documenter l'approche choisie.
Voir aussi la section sur la dépréciation.
Extensions¶
Si vous avez des champs qui n'ont pas de correspondance avec le schéma OCDS ou sur une extension existante, vous devriez les inclure dans vos données OCDS et créer une nouvelle extension pour documenter leur structure et leur signification.
Des extensions au standard peuvent ajouter de nouveaux objets et propriétés pour répondre à des besoins locaux spécifiques. Une nouvelle extension ne doit être créée que lorsqu'il est impossible de modéliser les données nécessaires en utilisant les termes existants du standard.
Les extensions doivent être documentées et partagées afin que les autres producteurs de données et utilisateurs puissent les utiliser, et qu'elles puissent être incluses dans une future version du standard.
Le registre des extensions publie des informations détaillées sur les extensions connues.
Le schéma du standard permet par défaut de nouveaux champs, et ne met pas en échec la validation d'un fichier qui contient des champs inconnus.