Esta página convierte las notas técnicas en una ruta de implementación práctica. No repite todos los documentos, pero ayuda a un equipo a decidir dónde ser estricto, dónde seguir siendo tolerante y cómo mantener alineados el parseo, la escritura y la validación.
El punto más importante de la nota técnica es la separación clara de responsabilidades.
La importación comienza detectando si la entrada es texto canónico `.eev`, un `.eevz` comprimido o un archivo `.eevc` / `.eevcz` ya emitido que solo debe leerse. La compresión no crea otro dialecto. Solo transporta texto canónico dentro de una envoltura binaria.
Una vez descomprimido si hace falta, cada variante pasa por el mismo parser de texto. Esta regla limita las desviaciones de comportamiento entre formas de transporte y conserva un único núcleo lógico para la lectura a nivel de aplicación.
El parser debe producir un modelo explícito: biblioteca, entradas, metadatos, global, matrices, vectores, modos, peak tracks y bloques opcionales. Ese modelo interno sirve para validar, mostrar y reexportar. No debe reducirse a un simple montón de líneas brutas.
El writer no debe improvisar. Reemite en un orden estable, con los campos actuales en su lugar correcto, sin reproducir ambigüedades legacy toleradas solo durante la lectura.
Library
├─ header
├─ entries[]
│ ├─ entry
│ ├─ manufacturer?
│ ├─ reseller?
│ ├─ global
│ ├─ vectors?
│ ├─ matrix?
│ ├─ modes?
│ ├─ peakTracks?
│ └─ therapeuticProfile?
└─ diagnostics[]Lo importante aquí es la legibilidad del modelo, no el lenguaje de implementación.
Un lector puede ser flexible. Un writer canónico debe seguir siendo predecible y deliberadamente sin sorpresas.
Definir un único orden de emisión y mantenerlo. Esto simplifica los diffs, las pruebas, la generación de hash y el mantenimiento.
Misma entrada, mismo modelo, misma salida. Una serialización determinista evita cambios falsos y refuerza la confianza en el formato.
El texto canónico sigue siendo la fuente funcional de verdad. La compresión `.eevz` llega después como etapa de transporte; un `.eevcz` existente puede releerse con esa misma lógica de compatibilidad.
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 validación no debe limitarse a decir “archivo inválido”. Debe explicar qué falta, qué es legacy, qué es contradictorio y qué puede repararse automáticamente sin traicionar el contrato canónico.
El hash funcional se aplica al texto canónico protegido, no a la envoltura comprimida. Esta regla evita duplicar sistemas de integridad y mantiene el centro de gravedad en el documento realmente significativo.
Esta síntesis sigue el espíritu de los documentos de QA y fallback para un equipo que implementa EEV dentro de un producto.
Probar `.eev` y `.eevz`, más la compatibilidad de solo lectura para archivos `.eevc` y `.eevcz` ya emitidos, entradas antiguas, campos ausentes y secciones desconocidas toleradas.
Verificar la estabilidad de las salidas, la emisión canónica de los campos modernos, el orden de los bloques y la ausencia de deriva entre dos exportaciones idénticas.
Probar en los entornos realmente objetivo, incluidos los casos degradados y las capturas de campo, no solo ejemplos ideales.