Résumé

  • RFC 5261 garantit la sélection d’un nœud unique dans le document cible fourni et la mutation définie ; il ne lie pas le diff à la révision courante voulue.
  • Une preuve exploitable conserve la base exacte, le contexte de namespace, les états intermédiaires, l’erreur, la transaction et l’observation de publication.

Le préfixe avait changé, pas l’espace de noms

Un service de présence recevait un diff utilisant le préfixe p, alors que le document cible employait un autre préfixe pour le même URI. Le processeur a correctement résolu l’identité d’espace de noms et appliqué le remplacement. Un consommateur aval, mal conçu, comparait pourtant les chaînes de préfixe et a interprété le résultat autrement.

Le patch respectait le modèle XML. L’application ne respectait pas sa propre abstraction.

Le sélecteur répond à une question locale

Chaque opération porte sel, limité à un sous-ensemble de XPath 1.0. Le résultat doit être un nœud unique ; zéro ou plusieurs résultats constituent une erreur. Noms, jokers, prédicats, valeurs et positions permettent de cibler précisément l’arbre courant.

Cette précision ne crée pas une identité durable. Une position change après insertion. Un attribut peut être réutilisé. id() dépend du type ID ou de xml:id et du support du processeur. Pour l’audit, le texte du sélecteur doit rester attaché au hachage de base et au hachage du nœud effectivement trouvé.

Chaque opération réécrit le terrain de la suivante

Les opérations add, replace et remove sont ordonnées. Le document produit par une opération devient la cible indépendante de la suivante. Une insertion peut donc déplacer l’indice positionnel que la prochaine opération utilisera.

Les nœuds de texte ajoutés ou retirés peuvent être fusionnés, car le modèle XML interdit deux nœuds texte adjacents. Les directives d’espace blanc peuvent aussi enlever des nœuds de présentation. L’ordre et les états intermédiaires sont des données de preuve, pas un détail d’implémentation.

L’erreur n’est pas un reçu de retour arrière

Une opération ambiguë ou impossible déclenche une erreur ; poursuivre ensuite est décrit comme peu sensé. Le RFC fournit des éléments d’erreur précis : nœud introuvable, types incompatibles, préfixe ou URI invalide, fonction ID non prise en charge, directive inconnue.

Le cadre ne définit pas une transaction de stockage universelle. Le protocole englobant doit dire si les états précédents ont été seulement calculés, écrits, exposés ou annulés. « Échec du patch » ne suffit donc pas : il faut le numéro d’opération, le dernier hachage intermédiaire et le résultat du rollback ou du commit.

L’URI et le préfixe sont deux réalités

Les préfixes sont locaux. Le diff et la cible peuvent employer des orthographes différentes pour le même URI. Le processeur peut réécrire un préfixe tout en conservant l’identité d’espace de noms. RFC 5261 précise aussi certains comportements de namespace par défaut qui diffèrent des attentes XPath ordinaires.

La conformité du processeur ne corrige pas un consommateur qui traite la graphie comme identité. Il faut tester les invariants de l’application après la mutation.

Canonique ne signifie pas approuvé

Le cadre utilise la forme XML canonique avec commentaires pour sa notion d’équivalence logique. Cette règle rend le traitement des espaces et des nœuds déterministe.

Elle ne garantit ni droit métier, ni politique de sécurité, ni portée d’une signature, ni approbation humaine. Un document bien formé, valide et canoniquement déterministe peut toujours violer le sens attendu.

La version reste un choix d’application

RFC 5261 reconnaît que certaines applications exigent l’historique complet, mais ne l’impose pas. Il avertit aussi que les sélecteurs positionnels courts dérivent après insertion ou suppression.

Une application qui exige la version courante doit ajouter ETag, génération ou hachage de base. Celle qui exige l’atomicité doit définir la transaction. Celle qui exige une autorité doit lier principal et portée.

Le reçu de patch

Conserver l’identité de cible, les octets et le hachage de base, version et ETag ; les octets du diff, type, charset, schéma, principal et autorisation ; l’ordre, le sélecteur et les bindings de namespace ; le chemin, type et hachage du nœud trouvé ; le contenu et chaque hachage intermédiaire ; l’erreur et l’opération fautive ; la politique de rollback/commit ; la validation XML et métier ; l’accusé de stockage, la réplication et la publication visible.

Ce reçu ne donne pas l’autorité. Il empêche une mutation locale correcte de devenir la preuve d’une mise à jour institutionnelle qui n’a jamais été établie.

Sources