Deze pagina zet de technische notities om in een praktisch implementatiepad. Ze herhaalt niet elk document, maar helpt een team te beslissen waar het strikt moet zijn, waar het tolerant kan blijven en hoe parsing, schrijven en validatie op elkaar afgestemd blijven.
Het belangrijkste punt in de technische notitie is de duidelijke scheiding van verantwoordelijkheden.
Import begint met het detecteren of de invoer canonieke tekst `.eev`, een gecomprimeerde `.eevz` of een reeds uitgegeven `.eevc` / `.eevcz`-bestand is dat alleen gelezen hoeft te worden. Compressie creëert geen ander dialect. Ze vervoert alleen canonieke tekst in een binaire verpakking.
Zodra de invoer indien nodig is gedecomprimeerd, gaat elke variant door dezelfde tekstparser. Deze regel beperkt gedragsafwijkingen tussen transportvormen en bewaart één logische kern voor lezen op applicatieniveau.
De parser moet een expliciet model opleveren: bibliotheek, entries, metadata, global, matrices, vectoren, modi, peak tracks en optionele blokken. Dat interne model dient voor validatie, weergave en herexport. Het mag niet verworden tot een losse hoop ruwe regels.
De writer mag niet improviseren. Hij geeft opnieuw uit in een stabiele volgorde, met de huidige velden op de juiste plaats, zonder legacy-ambiguïteiten te reproduceren die alleen tijdens het lezen worden getolereerd.
Library
├─ header
├─ entries[]
│ ├─ entry
│ ├─ manufacturer?
│ ├─ reseller?
│ ├─ global
│ ├─ vectors?
│ ├─ matrix?
│ ├─ modes?
│ ├─ peakTracks?
│ └─ therapeuticProfile?
└─ diagnostics[]Het belangrijkste punt hier is de leesbaarheid van het model, niet de gebruikte taal.
Een lezer kan flexibel zijn. Een canonieke writer moet voorspelbaar blijven en bewust verrassingsvrij werken.
Definieer één enkele uitvoervolgorde en houd die aan. Dit vereenvoudigt diffs, tests, hashgeneratie en onderhoud.
Zelfde entry, zelfde model, zelfde uitvoer. Deterministische serialisatie voorkomt schijnwijzigingen en versterkt het vertrouwen in het formaat.
Canonieke tekst blijft de functionele bron van waarheid. Compressie naar `.eevz` komt daarna als transportstap; een bestaand `.eevcz` kan met dezelfde compatibiliteitslogica worden gelezen.
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 textValidatie moet niet alleen “ongeldig bestand” zeggen. Ze moet uitleggen wat ontbreekt, wat legacy is, wat tegenstrijdig is en wat automatisch kan worden hersteld zonder het canonieke contract te schenden.
De functionele hash geldt voor de beschermde canonieke tekst, niet voor de gecomprimeerde verpakking. Deze regel voorkomt dubbele integriteitssystemen en houdt het zwaartepunt bij het werkelijk betekenisvolle document.
Deze synthese volgt de geest van de QA- en fallbackdocumenten voor een team dat EEV in een product implementeert.
Test `.eev` en `.eevz`, plus alleen-lezen-compatibiliteit voor reeds uitgegeven `.eevc`- en `.eevcz`-bestanden, oudere entries, ontbrekende velden en getolereerde onbekende secties.
Controleer uitvoerstabiliteit, canonieke uitgifte van moderne velden, blokvolgorde en het ontbreken van drift tussen identieke exports.
Test in de daadwerkelijk beoogde runtime-omgevingen, inclusief gedegradeerde gevallen en veldopnames, niet alleen ideale voorbeelden.