Cette page transforme les notes techniques en parcours d’implémentation concret. Elle ne recopie pas tous les documents, mais aide une équipe à décider où être stricte, où rester tolérante et comment garder alignés le parsing, l’écriture et la validation.
Le point le plus important de la note technique est la séparation nette des responsabilités.
L’import commence par détecter si l’entrée est un texte canonique `.eev`, un `.eevz` compressé, ou un fichier `.eevc` / `.eevcz` déjà émis qu’il faut seulement lire. La compression ne crée pas un autre dialecte du format. Elle transporte simplement un texte canonique dans une enveloppe binaire.
Une fois décompressé si nécessaire, chaque variante repasse par le même parseur texte. Cette règle limite les écarts de comportement entre formes de transport et préserve un seul cœur logique pour la lecture applicative.
Le parseur doit produire un modèle explicite : bibliothèque, entrées, métadonnées, global, matrices, vecteurs, modes, peak tracks et blocs optionnels. Ce modèle interne sert à la validation, à l’affichage et au réexport. Il ne doit pas se réduire à un simple tas de lignes brutes.
Le writer ne doit pas improviser. Il réémet dans un ordre stable, avec les champs actuels à leur bon endroit, sans reproduire les ambiguïtés legacy tolérées seulement en lecture.
Library
├─ header
├─ entries[]
│ ├─ entry
│ ├─ manufacturer?
│ ├─ reseller?
│ ├─ global
│ ├─ vectors?
│ ├─ matrix?
│ ├─ modes?
│ ├─ peakTracks?
│ └─ therapeuticProfile?
└─ diagnostics[]Le point important ici est la lisibilité du modèle, pas le langage utilisé.
Un lecteur peut rester souple. Un writer canonique, lui, doit rester prévisible et volontairement sans surprise.
Définir un ordre d’émission unique et le garder. Cela simplifie les diffs, les tests, la génération de hash et la maintenance.
Même entrée, même modèle, même sortie. Une sérialisation déterministe évite les faux changements et renforce la confiance dans le format.
Le texte canonique reste la source métier. La compression `.eevz` vient ensuite comme simple transport ; un `.eevcz` existant peut être relu dans ce même esprit de compatibilité.
read(input):
payload = detect_container_and_decode(input)
model = parse_canonical_text(payload.text)
diagnostics = validate(model)
return { model, diagnostics }
write(model, targetStatus, compressed):
normalized = normalize_for_canonical_output(model, targetStatus)
text = serialize_canonical_text(normalized)
if compressed:
return wrap_eevz_container(text, normalized.containerType)
return textLa validation ne doit pas seulement dire “fichier invalide”. Elle doit expliquer ce qui manque, ce qui est legacy, ce qui est contradictoire et ce qui peut être réparé automatiquement sans trahir le contrat canonique.
Le hash métier porte sur le texte canonique protégé, pas sur l’enveloppe compressée. Cette règle évite de dupliquer les logiques d’intégrité et garde le centre de gravité sur le document réellement signifiant.
Cette synthèse reprend l’esprit des documents QA et fallback pour une équipe qui implémente EEV dans un produit.
Tester `.eev` et `.eevz`, plus la compatibilité en lecture seule pour des fichiers `.eevc` et `.eevcz` déjà émis, les entrées anciennes, les champs manquants et les sections inconnues tolérées.
Vérifier la stabilité des sorties, la génération canonique des champs modernes, l’ordre des blocs et l’absence de dérive entre deux exports identiques.
Tester sur les environnements réellement visés, y compris les cas dégradés et les prises de son de terrain, pas seulement des exemples idéaux.