Résumé

  • JSON Type Definition vérifie la relation entre une instance et un contrat de structure volontairement restreint ; il ne statue pas sur la vérité du message.
  • Huit formes exclusives, une politique locale des propriétés inconnues et deux pointeurs d’erreur réduisent les divergences entre implémentations.
  • Après la validation restent l’authentification, l’autorisation, les règles métier, la fraîcheur, la persistance et la preuve du résultat.

Un objet annonce qu’une commande a été livrée. Le champ d’état appartient à l’énumération, l’identifiant est une chaîne, l’horodatage suit la grammaire attendue. Le validateur ne trouve rien à redire. Le colis peut pourtant être encore sur un quai, l’émetteur peut être usurpé et le message peut être une répétition d’hier.

RFC 8927 ne promet pas de résoudre ce problème. Il définit JSON Type Definition, ou JTD, pour décrire sans ambiguïté la forme courante de messages JSON, produire des types dans des langages ordinaires et localiser les erreurs de manière portable. Sa discipline tient autant à ce qu’il refuse qu’à ce qu’il accepte.

Une expérience, pas un sceau de consensus

Le document appartient à l’Independent Stream et porte le statut Experimental. Il n’exprime pas un consensus IETF et n’est pas une norme Internet. L’expérience sera probante si plusieurs implémentations indépendantes utilisent JTD pour échanger effectivement de l’information. Un numéro RFC ne constate donc ni adoption ni interopérabilité.

JTD limite son pouvoir expressif aux constructions proches des systèmes de types courants. Ses huit formes sont mutuellement exclusives : vide, référence, type, énumération, éléments, propriétés, valeurs et discriminateur. Une définition n’existe qu’à la racine ; une référence se résout dans ce vocabulaire commun. Cette contrainte évite qu’un même nom désigne un type différent selon la profondeur.

Le compromis est assumé. CDDL sait décrire des contraintes que JTD laisse de côté ; RFC 8927 emploie d’ailleurs CDDL pour décrire sa propre syntaxe, car JTD n’est pas assez expressif pour le faire. La simplicité n’est pas une prétention à l’exhaustivité. Elle dessine une petite zone où des outils différents peuvent espérer prendre la même décision.

Le schéma vide révèle la vraie portée du vert

La forme vide accepte toute instance et ne produit jamais d’erreur. Deux écrans peuvent donc afficher « conforme » alors que l’un a évalué un contrat détaillé et l’autre n’a posé aucune contrainte. Pour qu’un reçu soit exploitable, il faut conserver le condensat du message, celui du schéma, sa version, le moteur et le profil d’extensions.

Le membre metadata est tout aussi instructif. Il peut guider un générateur de code ou documenter un usage, mais les autres parties ne sont pas censées le comprendre. S’il change la validation, l’interopérabilité suppose un accord hors bande. Une annotation au nom solennel ne devient pas une règle partagée par sa seule présence.

Heng Lu distingue ici le symbole du fonctionnement. Le fichier de schéma annonce une coordination possible. Seuls les validateurs exécutés, les messages échangés et des résultats comparables attestent cette coordination.

La tolérance aux inconnus ne descend pas toute seule

Dans la forme properties, certaines propriétés sont obligatoires, d’autres facultatives, et un même nom ne peut appartenir aux deux ensembles. Par défaut, les membres non déclarés sont refusés. additionalProperties:true peut les autoriser, mais seulement dans l’objet où l’option apparaît.

Un objet racine ouvert n’ouvre donc pas automatiquement ses objets internes. Ce choix permet d’accepter de futurs champs de routage dans une enveloppe tout en gardant fermé un ordre financier imbriqué. Une bibliothèque qui transforme cette règle en interrupteur global fabrique une politique que le RFC n’a pas donnée.

La journalisation doit garder le niveau exact où un inconnu a été admis ou rejeté. Sans cette précision, « mode permissif » ne dit rien du périmètre réellement ouvert.

Deux coordonnées, aucun verdict métier

L’indicateur d’erreur standard associe instancePath, qui vise la donnée rejetée, et schemaPath, qui vise la règle correspondante. Ces deux JSON Pointer rendent une erreur reproductible. Ils n’en fixent toutefois pas l’ordre : le premier élément du tableau n’est ni forcément la cause première, ni le défaut le plus grave.

JSON Pointer indique une adresse documentaire. Il ne désigne pas le propriétaire de la décision et n’autorise aucune correction. Or l’automatisation confond volontiers précision géométrique et autorité. Une machine peut localiser /amount sans savoir si le prix était convenu.

Un temps bien écrit n’est pas un temps vrai

JTD distingue booléens, chaînes, nombres flottants, entiers signés ou non signés de 8 à 32 bits et horodatages. Les horodatages suivent RFC 3339, avec le resserrement utilisé par Atom. Cela normalise l’écriture ; cela ne prouve ni la source de l’horloge, ni l’occurrence de l’événement.

Le refus de int64 et uint64 illustre une gouvernance honnête. Les écosystèmes JSON ne conservent pas tous exactement l’ensemble de ces valeurs. I-JSON identifie une plage plus sûre autour de la précision binaire64. JTD préfère omettre un type plutôt que laisser son nom promettre une portabilité fictive.

De même, un discriminateur choisit une branche à partir d’une chaîne. Il peut exiger qu’un événement account_deleted contienne un identifiant ; il ne prouve pas la suppression. Il faut encore relier l’émetteur, son habilitation, l’acceptation de la commande et la lecture finale du stockage.

Le contrat peut devenir la charge hostile

Les références facilitent la réutilisation, mais un graphe cyclique peut enfermer une implémentation naïve dans une boucle. RFC 8927 recommande de détecter et d’abandonner ces cycles pour éviter le déni de service. RFC 8259 permet aussi des plafonds de taille, de profondeur et de précision.

Il faut donc traiter le validateur comme une ressource exposée : budget d’octets, de profondeur, d’expansion, de nombre d’erreurs et de temps. Un schéma JSON syntaxiquement correct peut rester une charge hostile. L’acteur qui supporte le risque doit garder la décision locale sur ces limites.

Sources

  1. RFC 8927 — JSON Type Definition
  2. RFC 8259 — Format d’échange JSON
  3. RFC 7493 — Format de message I-JSON
  4. RFC 6901 — JSON Pointer
  5. RFC 3339 — Date et heure sur Internet
  6. RFC 4287 — Format de syndication Atom
  7. RFC 8610 — Concise Data Definition Language
  8. Heng Lu — Running-Code Primacy
  9. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  10. Heng Lu — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile