Les références essentielles pour XML et quelques notes
| Auteur | Message |
|---|---|
|
Ce n’est que tardivement que ce sujet est ouvert dans cette partie du forum, parce qu’il semblait tellement évident que ça a été omis. Pourtant, comme quelques notes à ce sujet semble utiles et comme un sujet parlant de JSON et de XML a été ouvert, il y a deux bonnes raisons d’ouvrir ce sujet évident.
Les notes qui ont inspiré d’ouvrir ce sujet, seront dans le second message, mais ce premier message contient des notes aussi, alors il ne faut pas trop hâtivement considérer qu’il est a survolé pour n’en garder que les liens rapportés. D’abord les références les plus essentielles (donc pas toutes), ensuite quelques notes utiles, puis plus tard, des notes en rapport à propos de SGML et des DTD. On peut retrouver tous les standards concernant XML, à partir de cette page : W3C standards and drafts — XML (w3.org). C’est le page de recherche du W3C, en filtrant par status = standard et tag = XML. C’est de cette page que proviennent les références mentionnés ici, excepté deux qui s’obtiennent indirectement. Il existe deux versions de XML, ou plutôt trois. La première est XML 1.0. Elle est la plus courante, de loin. La seconde, est XML 1.1, qui n’a pas été très bien accueilli à son arrivé et qui n’a jamais trouvé autant de place que la première. C’est que dès que XML est arrivé, il s’est tellement installé partout, que même un changement de version mineur posait des problèmes. La troisième version est XML 2.0, qui a apparemment peu de chance d’être accepté un jour, pour les mêmes raisons, mais ça ne peut pas être affirmé non‑plus, l’avenir dira. XML 1.1 est quand même utile dans certains cas. La différence entre 1.0 et 1.1, est surtout celle du jeux de caractères autorisés. Au départ, XML 1.0 ne reconnaissait que les caractères définis dans Unicode 2, qui date d’il y a bien longtemps et Unicode en est à sa version 17. XML 1.1 a été conçu pour tenir comptes du fait que Unicode change avec le temps, en définissant de nouveaux caractères. Plus tard, XML 1.0 a été un peu corrigé au fil de plusieurs édition, pour inclure cet assouplissement introduit initialement par XML 1.1. Une partie des avancées de XML 1.1, ont fini par être incorporées à la version 1.0. Il y a les numéros de version mais aussi les éditions. XML 1.0 en est à l’édition № 5, qui ne semble pas changer depuis longtemps. XML 1.1 en est à l’édition № 2 qui ne semble pas changer non‑plus. Il faut faire attention à se référer à la dernière édition à chaque fois, l’erreur serait dommage, tellement les éditions précédentes sont anciennes. XML 1.1 n’est pas à ignorer, mais il est recommandé de ne l’utiliser que quand XML 1.0 ne peut vraiment pas l’être. Personnellement, je n’ai jamais vu de document qui soit en XML 1.1 alors ça semble rarement justifié.
On voit que la dernière révision de XML 1.0, est plus récente que la dernière révision de XML 1.1. C’est pour les références. Mais en pratiques, deux choses importantes sont définies indépendamment. Ce sont les espaces de nom et la canonicalisation.
Il y a une bizarrerie. La définition pour les espaces de nom, est mentionnée depuis la définition de XML 1.0 et depuis celle pour 1.1. Étrangement, la définition de XML 1.1 renvoi à la définition des espaces de nom pour XML 1.0, ce qui pourrait laisser penser que les deux utilisent la même. Pourtant, les deux documents ont un titre qui dit bien qu’il sont liés chacun à une version spécifique de XML. Là aussi, la dernière révision concernant XML 1.0, est plus récente. Il existe deux espaces de nom spéciaux, dont l’un est un véritable espace de noms et l’autre n’en est pas vraiment un.
“xml” est un vrai espace de noms, même s’il bénéficie d’un traitement à part, tandis que “xmlns” est seulement un préfixe, mais par commodité technique, il lui est associé un faux espace de noms. À ce propos, il n’y a pas de différence entre XML 1.0 et 1.1. Ces deux références ne se retrouvent pas par la page de recherche plus haut, elles sont mentionnées dans les références respectives de XML 1.0 et 1.1. Il y a une remarque subtile mais importante à faire sur le premier lien, celui pour l’espace de noms “xml”. L’URL donnée n’a pas de “.html” à la fin. Le même document est accessible aussi avec “.html” à la fin. Mais il vaut mieux n’utiliser que la première URL, sans le “.html”, parce que c’est la seule correcte pour désigner cet espace de noms. Le document qui le décrit et l’URL qui le désigne, sont deux choses différentes, mais il existe une convention fréquente bien que pas toujours appliquée, qui est que l’URI qui identifie un espace de noms, soit une URL accessible sur le web, à laquelle on peut trouver la description de cette espace de noms. Alors utiliser l’adresse avec le “.html”, pourrait introduire de la confusion, il faut éviter de la mentionner, même si cette page existe. Ensuite, deux standards moins souvent mentionnés mais que je trouve important et le premier des deux me semble même essentiel. Il en sera question dans les notes du second message de ce sujet.
Chaque fois que vous accéder à l’un de ces documents, vérifier de temps en temps si la version a changé ou pas. Excepté pour les deux à propos des espaces de nom spéciaux “xml” et “xmlns”, il existe pour chacun de ces documents, des adresses spécifiques à chaque version et une adresse qui renvoit toujours à la dernière version. Ce sont toujours ces liens qui sont donnés ici. S’il apparaît que la version a changé, il faut inspecter pour savoir ce qui a changé. La version précédente est toujours accessible au lien “Previous version”. En fait, ça vaut pour tous les standards du W3C, qui sont officiellement appelés des recommendations, mais même la page de recherche parle de standard, alors iels osent quand‑même les qualifier comme tels. Dans le message qui suivra, il y aura les notes promises. |
|
|
Sur les espaces de noms et les attributs, et surtout un genre de cas à considérer avec précaution.
On peut définir un espace de nom par défaut, mais comme on ne s’y attendrait pas, ça ne s’applique pas aux attributs. Les attributs peuvent avoir un préfixe désignant un espace de noms, mais ils ne peuvent pas être dans un espace de noms de par défaut, contrairement aux éléments. C’est apparemment sources de question, et ici, ce ne sont que mes réponses personnelles, d’autres gens peuvent avoir d’autres réponses et vous faire part des votre si elles sont fondées, justifiées ; ça sera plus intéressant que de n’avoir qu’un seul point de vue. Ce qu’en dit la référence est à un seul endroit : Namespaces in XML 1.0 — Third Edition — 6.2 Namespace Defaulting (w3.org), 8 Décembre 2009. W3C a écrit : The scope of a default namespace declaration extends from the beginning of the start-tag in which it appears to the end of the corresponding end-tag, excluding the scope of any inner default namespace declarations. In the case of an empty tag, the scope is the tag itself. C’est la même chose pour XML 1.1, à quelques petites différences près. En effet, il apparaît qu’en XML 1.1, on peut annuler la déclaration d’un espace de noms. Le reste semble pareil : Namespaces in XML 1.1 — Second Edition — 6.2 Namespace Defaulting (w3.org), 16 Août 2006. Dans le cas d’un élément vide, l’espace de noms par défaut, s’applique au délimiteur lui‑même. Mais ce délimiteur ne peut pas avoir d’autre contenu que des attributs et alors, en dehors de à l’élément lui‑même, à quoi d’autre l’espace de noms par défaut pourrait‑il donc s’appliquer. Par “ the tag itself ” faut–il seulement comprendre le nom de l’élément ou tout ce qu’il peut contenir, donc aussi les attributs ? C’est mi‑opaque mi‑transparent. Un attribut sans préfixe, n’est pas concerné par un espace de nom par défaut, même s’il en existe un, mais il l’est indirectement, sans dire comment. Son interprétation dépend seulement de l’élément qui le porte, ce qui en effet dépend de l’espace de nom par défaut s’il en existe un et que l’élément n’a pas de préfixe, ce qui justifie de dire que ça ne s’applique à l’attribut que indirectement. Mais c’est ainsi dans tous les cas où l’attribut n’a pas de préfixe, qu’il existe un espace de nom par défaut ou pas, que le nom de l’élément ait un préfixe ou pas. Mais un attribut peut quand‑même avoir un préfixe, et dans ce cas, c’est le préfixe qui dit comment interpréter l’attribut. Rien ne semble interdire qu’un éventuel préfixe, désigne le même espace de nom que celui de l’élément, que le préfixe utilisé soit le même ou pas et que l’élément ait son espace de noms de celui par défaut ou avec un préfixe. Un attribut sans préfixe n’est jamais associé à un espace de noms. C’est plus clair que le premier point et ça n’entre pas en contradiction avec le second, au point même de sembler assez redondant. La premier point, bien que vague, ne semble pas être en contradiction avec le second. Tout semble être dans le second point. Il semble clair, que techniquement, un attribut sans préfixe n’a pas d’espace de noms. On pourrait comprendre, mais ça n’est pas dit explicitement, que sémantiquement, c’est tout comme si quand il n’a pas de préfixe, il héritait quand‑même de l’espace de nom de l’élément sur lequel il se trouve, et ceci, qu’il existe un espace de nom par défaut ou pas. Même chose si l’élément n’a pas de référence à un espace de noms, dans les mêmes conditions, l’attribut n’en a sémantiquement pas non‑plus. Techniquement, pas d’espace de noms, mais sémantiquement, un espace de noms, oui. Il n’est pas possible de conclure trop vite que c’est comme s’il en avait un tout court, parce que quand dans un document on cherche des éléments ou des attributs par espace de nom, le résultat n’est pas le même. Si un attribut n’a pas de préfixe, il ne peut jamais être renvoyé dans les résultats d’une recherche d’attributs par espace de noms. Là, un aspect technique cause du tord à un aspect sémantique. Mais on ne peut pas redéfinir ce qui a été défini comme tel, le résultat serait encore pire. Mais définir une méthode alternative, qui fait comme si, pourquoi pas, pourvu que ça soit bien distingué. Il y a une autre question qui se pose, et elle ne se pose pas que dans ce cas là, c’est seulement que ce cas fait penser à cette question : il se peut qu’un attribut apparaisse sémantiquement plusieurs fois sur un même élément, alors qu’il n’apparaît pas textuellement plusieurs fois. S’il apparaît textuellement plusieurs fois, le XML est mal est syntaxiquement invalide. Mais avec les espaces de nom, cette garantie n’est pas suffisante pour garantir en conséquence qu’on a jamais d’attribut en double. Par exemple si ns1 et ns2 sont des liaison à un même espace de noms, alors ns1:attr et ns2:attr, sont un même attribut apparaissant sémantiquement plusieurs fois, même si textuellement ils semblent avoir des noms différents (c’est de l’aliasing). Il n’est en théorie pas exclus de donner une interprétation à ce qui n’est pas syntaxiquement incorrecte, mais ça serait alambiqué, puisqu’il y a l’idée implicite que les attributs ne sont pas et ne doivent pas être en double. Et ça, c’est plus sémantique que syntaxique. Solution proposée En le disant en secret, on peut temporairement considérer que un attribut sans préfixe, a techniquement le même espace de nom que l’élément sur lequel il se trouve et n’en a pas non‑plus si celui‑ci n’en a pas. Attention : l’élément peut avoir un espace de nom par défaut et alors l’attribut l’hérite aussi. On procède ainsi pour tous les attributs d’un élément. Ensuite, on vérifie pour chaque attribut si sa pair espace-de-nom/attribut est en double ou pas. Attention : on le fait avec les désignations des espaces de noms, pas avec les noms des préfixes. C’est important, parce que deux préfixes différents peuvent désigner un même espace de noms. Si un attribut apparaît être en double d’après ce test, on considère ça comme une erreur, même si l’analyse syntaxique du fichier a réussi. Disons qu’on le considère comme une erreur sémantique, la même que si ça avait été détecté comme une erreur syntaxique. Quand cette vérification est faite, on oublie qu’on a donné techniquement un espace de nom aux attributs qui ne devraient pas en avoir parce qu’ils n’ont pas de préfixe, on abandonne ces espaces de noms accordés temporairement pour le test, on revient à la normal. C’est un peu laborieux à lire, c’est seulement pour avoir plus de chance que rien d’important ne passe sous le seuil d’attention. C’est ce qui semble le mieux éviter les mauvaises surprises et je crois avoir compris que c’est ce que certaines gens font. Il faudrait savoir si ce procédé a déjà été écrit explicitement ailleurs. Si oui, ça confirmerait que l’idée n’est peut‑être pas mauvaise. En tous cas, c’est ce que je ferai personnellement, sinon ça me semble ouvert aux incohérences. |