Valider des documents OSIRIS JSON
La validation d’OSIRIS JSON n’est plus seulement une partie implicite de la specification. Elle dispose maintenant d’un modele documente, d’une frontiere canonique pour le moteur et d’un contrat CLI concu pour de vrais outils.
Les orientations actuelles sur la validation sont reparties dans trois documents en version brouillon publies en fevrier 2026: les Directives sur les niveaux de validation, le guide interne de Toolbox Core et le guide de Toolbox CLI. Ensemble, ils definissent comment les documents OSIRIS doivent etre valides de maniere coherente entre le developpement local, les integrations dans les editeurs et les pipelines CI.
La validation ne se limite pas au schema
L’une des decisions les plus claires du modele de validation d’OSIRIS est que JSON Schema, a lui seul, ne suffit pas.
Le projet definit la validation comme un pipeline a trois niveaux:
- Niveau 1: Structurel la validation verifie si un document est conforme au schema OSIRIS
- Niveau 2: Semantique la validation verifie l’integrite du graphe, notamment les references pendantes, les identifiants dupliques et les hierarchies de groupes invalides
- Niveau 3: Domaine la validation ajoute des recommandations optionnelles de bonnes pratiques qui ameliorent l’interoperabilite sans redefinir ce qui compte comme un OSIRIS valide
Cette separation est importante. Un document peut etre structurellement correct et pourtant rester dangereux a consommer si sa topologie n’est pas digne de confiance. OSIRIS traite ces situations comme des problemes differents et offre aux outils une maniere plus propre de les signaler.
Un moteur partage, pas des validateurs concurrents
L’architecture de validation est construite autour d’une seule regle: les outils de reference ne devraient pas inventer leur propre version de la verite.
@osirisjson/core est defini comme le moteur de validation canonique de l’ecosysteme. C’est le composant qui prend en charge le pipeline en trois etapes, le modele de diagnostic, l’aiguillage des schemas et la logique des profils. La CLI et les integrations dans les editeurs sont censees deleguer la validation a ce moteur partage plutot que de reimplementer les regles de maniere independante.
C’est un choix architectural fort, et c’est le bon. Cela signifie qu’un meme document devrait produire le meme resultat qu’il soit verifie en CI, inspecte dans un editeur ou traite par un outil de plus haut niveau construit sur la toolbox OSIRIS.
Les diagnostics sont le contrat
Un autre choix de conception important est qu’OSIRIS traite les diagnostics comme une interface structuree, et non comme une simple sortie texte.
Les resultats de validation s’appuient sur des codes V-* stables, des niveaux de severite, des messages et des chemins JSON Pointer. En pratique, cela signifie:
- Le code est le fait stable
- La severite est une politique faconnee par le profil actif
- Le message peut evoluer pour gagner en clarte sans casser les outils
C’est la difference entre une validation simplement visible et une validation qui peut vraiment etre automatisee. Les pipelines CLI, les infobulles dans les editeurs, les rapports lisibles par machine et les futures corrections rapides dependent tous de cette separation.
Concu pour le travail local et la CI
Le guide CLI est particulierement pragmatique. La validation est concue pour etre deterministe, privilegier le hors ligne et bien fonctionner dans le shell.
Le contrat documente prevoit:
- la prise en charge de
stdinpour la composition de pipelines - une sortie JSON lisible par machine pour la CI et l’automatisation
- des codes de sortie stables qui separent les echecs de validation des echecs operationnels
- une resolution hors ligne des schemas a l’aide de schemas integres ou mis en cache plutot que de recuperations reseau en direct
Les profils sont tout aussi pragmatiques:
basicse concentre uniquement sur les verifications structurellesdefaultexecute la validation structurelle et semantique pour le travail quotidienstrictajoute des verifications de domaine selectionnees pour les publications de producteurs et les seuils CI
Cela donne a OSIRIS un modele de validation capable de passer des retours dans l’editeur a la validation par lots sans changer le sens des regles sous-jacentes.
Pourquoi cela compte maintenant
Sans modele de validation partage, une norme ouverte commence a deriver presque immediatement. Chaque outil finit avec des hypotheses differentes, des severites differentes, des comportements de parseur differents et, au final, des definitions differentes de ce que signifie “valide”.
Ces directives sur la validation et la toolbox sont importantes parce qu’elles essaient d’arreter cette derive avant qu’elle ne commence. Elles rendent la validation reproductible, transmissible et portable dans l’ensemble de l’ecosysteme. Tout aussi important, elles maintiennent la confidentialite et la previsibilite dans le perimetre en exigeant un comportement de validation local et en evitant la dependance au reseau pendant les controles.
Lire les orientations de validation
Les documents actuels sur la validation et la toolbox sont publies comme orientations en brouillon: