Resumo

  • O sucesso segundo o RFC 5261 prova que um seletor encontrou um nó único no XML recebido e que a operação definida produziu um resultado; não prova que o documento era a versão-base vigente e pretendida.
  • Um recibo defensável deve vincular os bytes e a versão da base, o contexto do seletor, cada estado intermediário, o ponto de falha, a política de transação, a validação de negócio e a observação final de armazenamento e publicação.

Dois XML canônicos podem sustentar decisões opostas

Um sistema de benefícios substitui o valor de uma permissão e produz um documento bem-formado, válido pelo esquema e estável sob XML canônico. O processador fez exatamente o que a especificação pede. Ainda assim, a permissão entrou em vigor para a conta errada porque a cópia de base era antiga.

A equivalência canônica resolve um problema de representação: ajuda a determinar quando duas formas XML contam como logicamente equivalentes para o processamento. Ela não decide se um preço foi aprovado, se uma assinatura ainda cobre o conteúdo ou se uma transição de estado é permitida.

Essa separação importa porque a precisão sintática costuma adquirir uma autoridade que não possui. Um resultado determinístico continua podendo expressar a decisão errada.

O seletor só é único dentro da árvore entregue

Cada operação contém sel, uma expressão do subconjunto restrito de XPath 1.0. Ela deve localizar exatamente um alvo; nenhuma correspondência ou várias correspondências são erros. Nomes, curingas, predicados, valores, posições e, quando disponível, id() refinam a escolha.

Nada disso identifica por si só a revisão corrente de um objeto institucional. A inserção de um irmão muda índices posicionais. Um atributo pode reaparecer em outro ciclo de vida. O uso de id() depende do esquema, de xml:id e do suporte real do processador.

Por isso, guardar apenas o texto do seletor é pouco. O recibo precisa da versão ou ETag da base, do hash dos bytes, dos vínculos de namespace expandidos, do caminho efetivamente encontrado e do hash do nó antes da mudança.

A ordem transforma cada operação em contexto da próxima

Adicionar, substituir e remover não formam um conjunto sem ordem. Depois de uma operação bem-sucedida, o documento resultante vira o alvo independente da seguinte. Uma inserção pode deslocar um índice; uma remoção pode juntar nós de texto; uma reescrita de namespace pode alterar a representação observada por um consumidor defeituoso.

Dois patches com as mesmas instruções em ordens diferentes podem tocar nós diferentes e produzir estados diferentes. A ordem é parte do programa, não uma anotação de auditoria acrescentada depois.

Para mudanças relevantes, cada passo deve gerar um hash intermediário. Sem essa cadeia, o estado final não explica se o executor reordenou ações, pulou uma instrução ou continuou depois de uma falha.

Falha posterior não significa reversão universal

O RFC 5261 determina uma condição de erro quando uma operação não pode ser atendida sem ambiguidade e observa que prosseguir dificilmente faz sentido. Ele define elementos de erro para alvo não localizado, tipo incompatível, namespace, ID sem suporte e outras situações.

Mas não impõe uma única transação de armazenamento para todas as aplicações. Se duas operações produziram estados intermediários antes de uma terceira falhar, a persistência, a exposição e a reversão desses estados pertencem ao protocolo envolvente e à implementação.

“O patch falhou” não informa o estado real. É preciso registrar a operação que falhou, o último hash bem-sucedido, se algo foi gravado e qual resultado de rollback ou commit foi observado.

Prefixo é grafia; URI é identidade de namespace

Prefixos têm escopo local. O documento de diferença e o alvo podem usar grafias diferentes para a mesma URI, e o processador pode reescrever prefixos ao inserir conteúdo. O RFC 5261 também define comportamentos próprios para namespace padrão em certos seletores.

Uma troca de prefixo pode preservar integralmente o significado no modelo XML. Mesmo assim, código a jusante que trate a grafia como identidade pode mudar de comportamento. A conformidade do processador e a correção do consumidor são verificações separadas.

O recibo deve, portanto, registrar as associações expandidas de namespace no momento da seleção, não apenas os prefixos visíveis.

Texto e espaço em branco também participam da árvore

O modelo de dados XML não mantém nós de texto adjacentes como objetos separados. Adições, substituições e remoções podem uni-los. As diretivas de espaço em branco previstas pelo RFC podem retirar nós de formatação vizinhos.

Esses detalhes permitem resultados determinísticos. Também expõem integrações que confundem formatação com semântica. Uma interface pode parecer igual, enquanto um seletor posterior ou um consumidor sensível a texto recebe uma estrutura diferente.

O histórico de versões continua sendo responsabilidade da aplicação

O RFC reconhece que algumas aplicações precisam de um histórico completo, inclusive de mudanças aparentemente supérfluas, mas não estabelece um comportamento universal. Também alerta que seletores posicionais curtos são frágeis diante de inserções e remoções.

Essa é uma fronteira deliberada. Quem precisa de controle de concorrência deve acrescentar hash, geração, versão ou ETag. Quem precisa de atomicidade deve definir o ponto de commit. Quem precisa de legitimidade deve vincular principal, escopo e autorização à versão-base exata.

O recibo que separa execução de decisão

Para atualizações de alto impacto, preserve:

  • identidade do objeto, bytes exatos da base, hash, versão, ETag ou geração;
  • bytes e hash do diff, tipo de mídia, codificação, esquema e principal autenticado;
  • número ordenado da operação, seletor e namespaces expandidos;
  • caminho, tipo e hash anterior do nó encontrado;
  • conteúdo da operação e hash de cada documento intermediário;
  • erro, operação interrompida e último intermediário bem-sucedido;
  • política de rollback ou commit e o resultado observado;
  • hash final, validação de esquema e validação semântica da aplicação; e
  • confirmação de armazenamento, replicação e publicação visível.

Esse recibo não concede autoridade ao patch. Ele impede que “a expressão encontrou um nó” seja transformado em “a organização aprovou a alteração correta na versão correta”.

Sources