Resumen

  • Un selector único de RFC 5261 demuestra cuál nodo fue localizado en la base suministrada, no que esa base fuera la revisión correcta o autorizada.
  • La evidencia debe enlazar bytes de base, contexto XPath y namespaces, estados intermedios, error, rollback, validación semántica y publicación.

El tercer elemento seguía existiendo, pero ya era otra declaración

Un sistema regulatorio eliminaba */*[3]/*[2] de un expediente XML. Antes de recibir el diff, otro proceso insertó un hermano. El selector posicional siguió encontrando exactamente un nodo y remove se ejecutó sin ambigüedad. Había quitado la declaración equivocada.

El protocolo funcionó. La identidad empresarial se había reducido a una coordenada móvil.

Un único resultado no es una identidad duradera

sel usa un subconjunto de XPath 1.0 y debe localizar un solo objetivo. Cero o varios resultados son error. Predicados de atributo o valor suelen ser más estables que posiciones; id() puede ayudar cuando el modelo declara IDs y el procesador los admite.

Pero incluso un ID puede pertenecer a una versión obsoleta o reutilizarse según reglas externas. El selector debe quedar unido al hash de la base, bindings expandidos y hash del nodo previo. Sin eso, solo sabemos que una expresión coincidió en algún árbol.

El orden modifica las coordenadas siguientes

Cada documento parchado se convierte en objetivo independiente de la operación posterior. Una inserción cambia índices de hermanos. Una eliminación puede unir nodos de texto. Las directivas de espacio en blanco pueden quitar nodos vecinos.

Por eso, la secuencia y cada estado intermedio forman parte del significado. Reordenar operaciones similares no es una optimización inocua.

Fallar no significa necesariamente deshacer

RFC 5261 declara error cuando una operación no puede cumplirse sin ambigüedad y aconseja no continuar. Define errores específicos para nodo no localizado, tipos incompatibles, namespaces, ID, prólogo y directivas.

No impone una transacción de almacenamiento universal. El contenedor decide si resultados previos eran temporales, persistidos, visibles o revertidos. Un recibo debe indicar operación fallida, último estado correcto y resultado real de rollback o commit.

El namespace vive en el URI

Prefijos distintos pueden representar el mismo URI. El diff y la base resuelven bindings en sus propios contextos, y el procesador puede cambiar prefijos al incorporar contenido. También hay reglas deliberadas sobre namespaces por defecto.

La transformación puede ser correcta aunque un consumidor defectuoso dependa de la ortografía del prefijo. La validación del modelo XML y la validación de todos los consumidores son controles diferentes.

Equivalencia canónica no es equivalencia institucional

La forma XML canónica con comentarios sostiene el determinismo del marco. La atención a texto y espacios conserva su modelo lógico.

Nada de eso confirma derechos, límites de una firma, estados de flujo o aprobación humana. Un resultado válido y canónico puede violar invariantes que el esquema nunca expresó.

La aplicación debe aportar versión y autoridad

El RFC deja el historial completo a cada aplicación y advierte sobre selectores posicionales. Cuando importa la actualidad, hacen falta hash, generación o ETag. Cuando importa atomicidad, hacen falta límites transaccionales. Cuando importa autoridad, hacen falta principal y alcance.

Recibo de aplicación

Guardar identidad y bytes de la base, hash, versión y ETag; diff, tipo, charset, esquema y principal; número de operación, selector y bindings; ruta, tipo y hash previo del nodo; contenido y hashes intermedios; error y último éxito; política y resultado de rollback/commit; hash final y validaciones; confirmación de almacenamiento, réplica y publicación visible.

El recibo no transforma una mutación en aprobación. Conserva la diferencia entre modificar bien un árbol y modificar el árbol correcto.

Sources