Resumo

  • A RFC 1197 tratou ODA como uma arquitetura abstrata para documentos compostos. Para usá-la como meio de intercâmbio, era preciso um document application profile e um mapa entre o perfil e os objetos nativos de cada aplicativo.
  • O projeto EXPRES, financiado pela NSF, usou um perfil do NIST diante das funções de Andrew, Diamond e Interleaf. A RFC identifica a experiência, mas não publica medidas de fidelidade, round trip ou adoção.
  • As regras posteriores de MIME e X.400 transportaram body, profile e class em superfícies distintas. Copiar os bytes não comprovava interpretação, renderização, editabilidade ou conclusão da tarefa.

O perfil era uma decisão de comunidade, não um detalhe de arquivo

Chamar um arquivo de ODA dizia em qual família de representação ele estava. Não dizia, sozinho, quais partes da família seriam utilizadas. A RFC 1197 tornou essa distância explícita ao exigir um document application profile, ou DAP, para o intercâmbio efetivo.

O perfil escolhia entidades comuns dentro da arquitetura. Cada sistema ainda construía um mapa entre essas entidades e seu próprio modelo. A primeira decisão pertencia à comunidade que precisava trocar documentos; a segunda, a quem implementava o editor ou conversor.

Essa divisão impede que “compatível com ODA” funcione como veredicto total. Dois produtos podem reconhecer o padrão e adotar perfis diferentes. Podem adotar o mesmo perfil e divergir em propriedades opcionais, extensões ou comportamento local. A interseção real precisa ser nomeada e testada.

Um perfil estreito não é uma derrota da especificação ampla. É a forma de reduzir opções a uma promessa executável. Recursos exclusivos continuam disponíveis dentro de cada produto, sem ganhar portabilidade por associação.

O parágrafo estava abaixo do nível escolhido pela arquitetura

Mark Sherman publicou RFC 1197 em dezembro de 1990. O registro do RFC Editor e o registro do IETF Datatracker a classificam como Informational; ela não estabelecia um Internet Standard.

O texto descreve ISO 8613 Office Document Architecture, também ligado a CCITT T.410, como um padrão para documentos com texto em várias fontes, imagens raster e gráficos geométricos. Era uma tentativa de representar objetos compostos sem transformar um editor específico em modelo universal.

Por isso seu vocabulário era abstrato. A RFC cita composite logical object classes e observa que ODA não definia entidades comuns como parágrafos no mesmo nível. A conclusão correta não é que um documento ODA jamais pudesse conter estrutura equivalente. É que a arquitetura geral não escolhera por conta própria o objeto prático compartilhado.

Quanto mais neutro o núcleo, mais visível deve ser o trabalho de adaptação. A abstração abre participação para sistemas diferentes; o DAP e os mapas locais fecham as ambiguidades necessárias para uma troca concreta.

EXPRES partiu de sistemas realmente diferentes

A National Science Foundation financiou EXPRES para investigar propostas de pesquisa enviadas por correio eletrônico com ODA como meio de intercâmbio. Participaram grupos de Carnegie Mellon University e University of Michigan, em colaboração com McDonnell-Douglas Aerospace Information Systems, NIST e Interleaf.

As estratégias se basearam no NIST DAP e nas funções disponíveis em Andrew, Diamond e Interleaf. A lista mostra por que o mapa era necessário: o perfil comum precisava encontrar três superfícies de aplicação, não três cópias do mesmo modelo.

Mas a RFC tem apenas duas páginas. As estratégias completas foram remetidas a um livro de 1991 que não integra este conjunto de fontes. Não há, na nota, índice de conversão, comparação visual, teste de ida e volta, desempenho ou confirmação de que uma proposta específica completou o processo da NSF.

Proveniência não é resultado. Os nomes registram os participantes da investigação descrita. Não provam suporte atual, qualidade global dos produtos ou adoção posterior. O próprio texto separa as opiniões dos autores das políticas das instituições.

MIME precisou declarar o DAP ao lado do tipo

Em 1992, a RFC 1341 definiu application/oda no MIME inicial. O subtype dizia que o body usava os padrões ODA na representação ODIF. A linha Content-Type também deveria levar um parâmetro profile, com profile=Q112 como exemplo.

Os dois nomes respondiam a perguntas diferentes. O subtype identificava a arquitetura; o parâmetro delimitava o contrato aplicativo. Se “ODA” já determinasse todas as entidades úteis, o profile adicional não teria função.

O header ajudava o receptor a escolher um agente. Não comprovava que o agente entendia Q112, que todos os objetos do body eram suportados ou que a aparência e a estrutura editável permaneceriam iguais. RFC 1341 hoje é obsoleta; aqui ela vale como registro histórico dessa divisão, não como orientação atual de MIME.

Byte copy mantinha o artefato e deixava decisões ao redor

A RFC 1494, de 1993, definiu equivalências entre body parts X.400 e MIME. Para ODA, a conversão do corpo era “Byte copy”. A passagem não precisava reescrever os dados ODA.

Separadamente, o identificador X.400 de document-application-profile era mapeado para profile, e document-architecture-class para formatted, processable ou formatted-processable. A identidade dos bytes, a declaração do perfil e a classe eram registros distintos.

Quando parâmetros faltavam na direção MIME para X.400, a regra adotava Q112 e formatted-processable. O gateway podia procurar as características dentro do documento, mas não era obrigado, pois esses campos internos eram opcionais.

O default torna a execução previsível. Não reconstrói uma escolha do remetente que nunca foi registrada. Por isso uma trilha confiável deve distinguir valor declarado, extraído e preenchido pela regra.

“Byte copy” também não é sinônimo de fidelidade semântica. Ele limita a alegação ao body: os bytes não mudaram naquele passo. Capacidade do receptor, interpretação do perfil e comportamento do mapa local continuam sem resposta.

O registro Experimental tornou a ameaça dependente do tempo

Em janeiro de 1998, a RFC 2161 reuniu as definições ODA de MIME e X.400. Era Experimental e afirmava que não constituía Internet Standard de nenhum tipo. Preservou profile, class, Q112 e as três classes documentais.

Seu campo “Conversion: None” dizia que o corpo continuava ODA. Não eliminava o mapeamento de metadados, o uso de defaults nem a interpretação pelo destinatário.

A seção de segurança notou que bodies ODA podiam conter estruturas complexas, difíceis de inspecionar quanto às capacidades. Como a arquitetura era extensível, novas porções de conteúdo poderiam alterar ameaças com o tempo. O mesmo trecho dizia não haver então risco conhecido específico de ODA. A fonte justifica inventário e revisão, não a invenção de um ataque histórico.

Um media type pode permanecer estável enquanto profile, extensões, parser e adaptador mudam. “Suportado” precisa portanto de artifact, versão e resultado, não apenas um selo permanente.

A prova terminava no documento observado, não no parse

A cadeia começa com bytes ODIF e segue por type, origem do profile, class, ação do gateway, suporte receptor e mapa local. Depois vêm renderização, estrutura mantida, editabilidade, round trip e resultado institucional.

Um hash responde se o arquivo mudou. Um profile indica o subconjunto alegado. A versão do adaptador identifica regras. Só uma comparação da saída responde o que ocorreu com página, objeto e estrutura. Cada evidência tem utilidade e limite.

O parágrafo de RFC 1197 não condena padrões abstratos. Ele mostra a responsabilidade que a abstração distribui. O núcleo fornece uma forma comum; o profile escolhe uma linguagem praticável; as bordas executam a tradução; o destinatário decide se recebeu o documento necessário.

Fontes e limites

As fontes não comprovam uso atual, participação de mercado, qualidade de produto, fidelidade quantitativa do EXPRES, incidente conhecido nem sucesso de uma proposta específica.