Diese Seite übersetzt die technischen Notizen in einen praktischen Implementierungsweg. Sie wiederholt nicht jedes Dokument, sondern hilft einem Team zu entscheiden, wo es strikt sein muss, wo es tolerant bleiben kann und wie Parsing, Schreiben und Validierung zusammenpassen.
Der wichtigste Punkt der technischen Notiz ist die klare Trennung der Verantwortlichkeiten.
Der Import beginnt damit zu erkennen, ob die Eingabe kanonischer Text `.eev`, ein komprimiertes `.eevz` oder eine bereits ausgestellte `.eevc`- / `.eevcz`-Datei ist, die nur gelesen werden muss. Kompression schafft keinen anderen Dialekt. Sie transportiert nur kanonischen Text in einer binären Hülle.
Nach dem Dekomprimieren, falls nötig, läuft jede Variante durch denselben Textparser. Diese Regel begrenzt Verhaltensabweichungen zwischen Transportformen und bewahrt einen einzigen logischen Kern für das Lesen auf Anwendungsebene.
Der Parser sollte ein explizites Modell erzeugen: Bibliothek, Einträge, Metadaten, global, Matrizen, Vektoren, Modi, Peak Tracks und optionale Blöcke. Dieses interne Modell dient Validierung, Anzeige und Re-Export. Es sollte nicht zu einem losen Haufen von Rohzeilen verkommen.
Der Writer darf nicht improvisieren. Er gibt in stabiler Reihenfolge erneut aus, mit den aktuellen Feldern an der richtigen Stelle, ohne Legacy-Mehrdeutigkeiten zu reproduzieren, die nur beim Lesen toleriert werden.
Library
├─ header
├─ entries[]
│ ├─ entry
│ ├─ manufacturer?
│ ├─ reseller?
│ ├─ global
│ ├─ vectors?
│ ├─ matrix?
│ ├─ modes?
│ ├─ peakTracks?
│ └─ therapeuticProfile?
└─ diagnostics[]Wichtig ist hier die Lesbarkeit des Modells, nicht die verwendete Sprache.
Ein Reader kann flexibel sein. Ein kanonischer Writer muss vorhersehbar bleiben und bewusst ohne Überraschungen arbeiten.
Eine einzige Ausgabereihenfolge definieren und beibehalten. Das vereinfacht Diffs, Tests, Hash-Erzeugung und Wartung.
Gleicher Eintrag, gleiches Modell, gleiche Ausgabe. Deterministische Serialisierung vermeidet Scheinänderungen und stärkt das Vertrauen in das Format.
Der kanonische Text bleibt die fachliche Wahrheitsquelle. Die Kompression `.eevz` kommt danach als Transportschritt; eine vorhandene `.eevcz` kann mit derselben Kompatibilitätslogik gelesen werden.
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 textValidierung sollte nicht nur “ungültige Datei” sagen. Sie sollte erklären, was fehlt, was Legacy ist, was widersprüchlich ist und was automatisch repariert werden kann, ohne den kanonischen Vertrag zu verraten.
Der fachliche Hash bezieht sich auf den geschützten kanonischen Text, nicht auf die komprimierte Hülle. Diese Regel vermeidet doppelte Integritätssysteme und hält den Schwerpunkt beim tatsächlich bedeutungsvollen Dokument.
Diese Zusammenfassung folgt dem Geist der QA- und Fallback-Dokumente für ein Team, das EEV in ein Produkt integriert.
`.eev` und `.eevz` testen, dazu Nur-Lese-Kompatibilität für bereits ausgestellte `.eevc`- und `.eevcz`-Dateien, ältere Einträge, fehlende Felder und tolerierte unbekannte Abschnitte.
Ausgabestabilität, kanonische Ausgabe moderner Felder, Blockreihenfolge und das Ausbleiben von Drift zwischen identischen Exporten prüfen.
In den tatsächlich anvisierten Laufzeitumgebungen testen, einschließlich degradierter Fälle und Feldaufnahmen, nicht nur an idealen Beispielen.