Esta página transforma as notas técnicas num percurso prático de implementação. Não repete todos os documentos, mas ajuda uma equipa a decidir onde ser rigorosa, onde manter tolerância e como alinhar parsing, escrita e validação.
O ponto mais importante da nota técnica é a separação clara das responsabilidades.
A importação começa por detetar se a entrada é texto canónico `.eev`, um `.eevz` comprimido ou um ficheiro `.eevc` / `.eevcz` já emitido que apenas precisa de ser lido. A compressão não cria outro dialeto. Limita-se a transportar texto canónico numa envolvente binária.
Depois de descomprimido, se necessário, cada variante passa pelo mesmo parser de texto. Esta regra limita desvios de comportamento entre formas de transporte e preserva um único núcleo lógico para a leitura ao nível da aplicação.
O parser deve produzir um modelo explícito: biblioteca, entradas, metadados, global, matrizes, vetores, modos, peak tracks e blocos opcionais. Esse modelo interno serve para validação, visualização e reexportação. Não deve reduzir-se a um simples monte de linhas brutas.
O writer não deve improvisar. Reemite numa ordem estável, com os campos atuais no sítio certo, sem reproduzir ambiguidades legacy toleradas apenas na leitura.
Library
├─ header
├─ entries[]
│ ├─ entry
│ ├─ manufacturer?
│ ├─ reseller?
│ ├─ global
│ ├─ vectors?
│ ├─ matrix?
│ ├─ modes?
│ ├─ peakTracks?
│ └─ therapeuticProfile?
└─ diagnostics[]O ponto importante aqui é a legibilidade do modelo, não a linguagem usada.
Um leitor pode ser flexível. Um writer canónico deve manter-se previsível e deliberadamente sem surpresas.
Definir uma única ordem de emissão e mantê-la. Isto simplifica diffs, testes, geração de hash e manutenção.
Mesma entrada, mesmo modelo, mesma saída. Uma serialização determinística evita alterações falsas e reforça a confiança no formato.
O texto canónico continua a ser a fonte funcional de verdade. A compressão `.eevz` vem depois como etapa de transporte; um `.eevcz` existente pode ser relido com essa mesma lógica de compatibilidade.
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 textA validação não deve limitar-se a dizer “ficheiro inválido”. Deve explicar o que falta, o que é legacy, o que é contraditório e o que pode ser reparado automaticamente sem trair o contrato canónico.
O hash funcional aplica-se ao texto canónico protegido, não à envolvente comprimida. Esta regra evita duplicar sistemas de integridade e mantém o centro de gravidade no documento realmente significativo.
Esta síntese segue o espírito dos documentos de QA e fallback para uma equipa que implementa EEV num produto.
Testar `.eev` e `.eevz`, mais a compatibilidade apenas de leitura para ficheiros `.eevc` e `.eevcz` já emitidos, entradas antigas, campos em falta e secções desconhecidas toleradas.
Verificar a estabilidade das saídas, a emissão canónica dos campos modernos, a ordem dos blocos e a ausência de deriva entre duas exportações idênticas.
Testar nos ambientes de runtime realmente visados, incluindo casos degradados e captações de campo, e não apenas exemplos ideais.