Appendix A. Notes on Processing XML Elements (Notes sur le traitement des éléments XML)

Annexe A. Notes on Processing XML Elements (Notes sur le traitement des éléments XML)

A.1. Notes on Empty XML Elements (Notes sur les éléments XML vides)

XML prend en charge deux mécanismes pour indiquer qu'un élément XML n'a aucun contenu. Le premier consiste à déclarer un élément XML de la forme <A></A>. Le second consiste à déclarer un élément XML de la forme <A/>. Les deux éléments XML sont sémantiquement identiques.

A.2. Notes on Illegal XML Processing (Notes sur le traitement XML illégal)

XML est un format de données flexible qui permet de soumettre facilement des données qui semblent légales mais ne le sont pas en réalité. La philosophie "Soyez flexible dans ce que vous acceptez et strict dans ce que vous envoyez" s'applique toujours, mais elle ne doit pas être appliquée de manière inappropriée. XML est extrêmement flexible dans le traitement des questions d'espaces blancs, d'ordre des éléments, d'insertion de nouveaux éléments, etc. Cette flexibilité ne nécessite pas d'extension, en particulier dans le domaine de la signification des éléments.

Il n'y a aucune gentillesse à accepter des combinaisons illégales d'éléments XML. Au mieux, cela provoquera un résultat indésirable et au pire, cela peut causer des dommages réels.

A.3. Example - XML Syntax Error (Exemple - Erreur de syntaxe XML)

Le corps de requête suivant pour une méthode PROPFIND est illégal.

<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
 <D:allprop/>
 <D:propname/>
</D:propfind>

La définition de l'élément propfind ne permet que l'élément allprop ou l'élément propname, pas les deux. Ainsi, ce qui précède est une erreur et doit recevoir une réponse 400 (Bad Request).

Imaginez cependant qu'un serveur veuille être "gentil" et décide de choisir l'élément allprop comme véritable élément et d'y répondre. Un client fonctionnant sur une ligne à bande passante limitée qui avait l'intention d'exécuter un propname serait très surpris si le serveur traitait la commande comme un allprop.

De plus, si un serveur était indulgent et décidait de répondre à cette demande, les résultats varieraient de manière aléatoire d'un serveur à l'autre, certains serveurs exécutant la directive allprop et d'autres exécutant la directive propname. Cela réduit l'interopérabilité au lieu de l'augmenter.

A.4. Example - Unexpected XML Element (Exemple - Élément XML inattendu)

L'exemple précédent était illégal car il contenait deux éléments explicitement interdits d'apparaître ensemble dans l'élément propfind. Cependant, XML est un langage extensible, on peut donc imaginer de nouveaux éléments définis pour être utilisés avec propfind. Voici le corps de requête d'un PROPFIND et, comme l'exemple précédent, doit être rejeté avec un 400 (Bad Request) par un serveur qui ne comprend pas l'élément expired-props.

<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:"
xmlns:E="http://www.example.com/standards/props/">
 <E:expired-props/>
</D:propfind>

Pour comprendre pourquoi un 400 (Bad Request) est renvoyé, examinons le corps de requête tel que le serveur non familier avec expired-props le voit.

<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:"
            xmlns:E="http://www.example.com/standards/props/">
</D:propfind>

Comme le serveur ne comprend pas l'élément 'expired-props', selon les règles de traitement XML spécifiques à WebDAV spécifiées dans la section 17, il doit traiter la demande comme si l'élément n'était pas là. Ainsi, le serveur voit un propfind vide, qui selon la définition de l'élément propfind est illégal.

Veuillez noter que si l'extension avait été additive, cela n'aurait pas nécessairement entraîné un 400 (Bad Request). Par exemple, imaginez le corps de requête suivant pour un PROPFIND:

<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:"
            xmlns:E="http://www.example.com/standards/props/">
 <D:propname/>
 <E:leave-out>*boss*</E:leave-out>
</D:propfind>

L'exemple précédent contient l'élément fictif leave-out. Son but est d'empêcher le retour de toute propriété dont le nom correspond au modèle soumis. Si l'exemple précédent était soumis à un serveur non familier avec 'leave-out', le seul résultat serait que l'élément 'leave-out' serait ignoré et un propname serait exécuté.