Représenter des grandeurs physiques en JSON : valeur, unité et précision en champs séparés

Objectif

Échanger des grandeurs mesurées ou calculées en JSON, de façon à ce qu'un consommateur puisse déterminer le nombre, l'unité et la part significative de ce nombre, sans avoir à deviner à partir du nom du champ.

Prérequis

Une liste des types de grandeurs que transporte l'interface (longueur, masse, durée, température ; les montants monétaires sont traités séparément), une décision sur un vocabulaire d'unités, et un accord sur le fait que chaque champ soit à unité fixe (tous les producteurs utilisent la même unité) ou à unité variable (le producteur choisit).

Étapes

1. Pour chaque type de grandeur, choisir une unité canonique unique pour le stockage et les calculs, de préférence l'unité SI ou une unité dérivée cohérente (mètres, kilogrammes, secondes), et convertir à la frontière.
2. Champs à unité fixe : placer l'unité dans le nom du champ (duration_ms, distance_m) et utiliser un simple nombre JSON. C'est compact et difficile à mal lire.
3. Champs à unité variable (valeurs saisies par l'utilisateur, instruments avec leurs propres unités) : utiliser un objet {"value": 12.5, "unit": "kg"}, avec unit tiré d'un vocabulaire contrôlé. UCUM (cité) fournit des codes d'unité lisibles par machine en ASCII ; il définit des symboles sensibles à la casse (kg, Cel, [in_i]) ainsi qu'une variante distincte insensible à la casse, donc préciser quelle variante l'interface utilise.
4. Faire porter la précision explicitement lorsqu'elle compte : un champ séparé uncertainty ou resolution, pas des zéros de fin. La RFC 7946 (citée) pose cette règle pour les coordonnées, en précisant que le nombre de chiffres ne doit pas être interprété comme une indication d'incertitude ; les analyseurs syntaxiques ne préservent pas le nombre de chiffres, donc la règle vaut pour toute grandeur.
5. Utiliser une chaîne de caractères portant une représentation décimale lorsque la valeur décimale exacte compte (une lecture recopiée d'un afficheur, une limite réglementaire) ; utiliser des nombres JSON pour les valeurs approximatives par nature.
6. Valider dans le schéma : une énumération pour unit, une plage numérique par unité, et une règle selon laquelle value et unit apparaissent ensemble ou pas du tout.
7. Traiter la température à part : UCUM classe le degré Celsius comme une unité spéciale sur une échelle qui n'est pas de rapport, convertie par un décalage plutôt que par un facteur, et exclue de la multiplication et de l'exponentiation ; stocker le kelvin ou le Celsius, et préciser lequel.

Résultat attendu

Un consommateur peut convertir mécaniquement toute valeur vers son unité canonique, les incompatibilités d'unité sont détectées par la validation de schéma plutôt que de se traduire par des résultats erronés, et les affirmations de précision sont explicites plutôt que déduites du formatage.

Limites et base de vérification

Cette procédure est une proposition dérivée des spécifications citées ; aucune mesure de son effet n'est revendiquée. Elle ne couvre pas les montants monétaires, qui ont leurs propres règles (unités mineures par devise), ni les unités composées dont les codes doivent être assemblés (kg.m/s2 en syntaxe UCUM). Les vocabulaires d'unités diffèrent (UCUM, codes UN/CEFACT, ontologies) ; les mélanger dans une même interface va à l'encontre du but recherché, donc en choisir un et consigner ce choix dans le schéma.