C'est une chose que je trouve toujours un peu difficile à expliquer aux autres : Pourquoi les espaces de noms XML existent-ils ? Quand faut-il les utiliser et quand ne faut-il pas le faire ? Quels sont les pièges courants lorsqu'on travaille avec des espaces de noms en XML ?
En outre, quel est leur rapport avec les schémas XML ? Les schémas XSD doivent-ils toujours être associés à un espace de noms ?
Ils permettent de combiner plusieurs langages de balisage sans avoir à se soucier des conflits de noms d'éléments et d'attributs.
Par exemple, regardez n'importe quel bout de code XSLT, puis pensez à ce qui se passerait si vous n'utilisiez pas les espaces de noms et que vous essayiez d'écrire un XSLT dont la sortie doit contenir des éléments "template", "for-each", etc. Des erreurs de syntaxe, voilà ce qui arriverait.
Je laisserai les conseils et les pièges à ceux qui ont plus d'expérience que moi.
Pourquoi les espaces de noms XML existent-ils ?
Parce qu'en 1997, certaines personnes très influentes du W3C les voulaient et n'acceptaient pas de refus. Même lorsqu'il a été démontré, j'ose dire de manière concluante, qu'il existait de meilleures façons de résoudre le "problème" qu'ils pensaient avoir, ils ont tout de même exercé leur influence pour que leurs désirs soient consignés dans une recommandation du W3C.
Le plus gros mensonge dans la mythologie désormais très répandue qui entoure les espaces de noms XML est qu'ils ont un mérite technique. (Il s'agit de l'effet en aval d'une recommandation qui existe simplement et qui occupe donc l'espace des esprits - "Bon sang, il doit y avoir une (bonne) raison ! - par opposition à une note de bas de page oubliable quelque part).
Beaucoup de douleur, aucun gain .
Quand faut-il les utiliser et quand ne faut-il pas le faire ?
Vous ne devriez jamais les utiliser si vous pouvez l'éviter. Malheureusement, la promotion incessante de ce dispositif MAUVAIS [*] par les parties intéressées a donné naissance à un amas de spécifications qui rendent pratiquement impossible de ne pas être confronté aux espaces de noms XML à un moment ou à un autre. Ainsi, même si vous évitez vous-même les espaces de noms XML, vous trouverez des saletés incrustées d'espaces de noms qui vous tomberont dessus de toutes les directions, ou pire, des ensembles d'outils qui refusent tout simplement de fonctionner si vous ne leur donnez pas ces saletés.
Quels sont les pièges courants lorsque l'on travaille avec des espaces de noms dans le XML ?
Un piège très courant consiste à utiliser les expressions Xpath avec des documents où un espace de noms a été "par défaut" : l'espace de noms devra être explicite dans les expressions. Un autre problème consiste à les utiliser "correctement" lors de la construction de documents : ils créent des problèmes à partir de rien .
En outre, comment se rapportent-ils aux schémas XML ? Les schémas XSD doivent-ils toujours être associés à un espace de noms ?
Il n'y a pas de relation nécessaire, si ce n'est que la spécification XSD Schema a été élaborée à une époque où presque tous les membres du comité avaient déjà l'espace de nommage XML entre les dents. Ils l'ont donc intégré aussi profondément qu'ils le pouvaient. Il est néanmoins possible d'utiliser des schémas XSD sans espaces de noms, mais il s'agit d'un parcours semé d'embûches, car presque tous les outils prenant en charge les schémas XSD partent du principe que vous "voudrez" utiliser les espaces de noms.
[*] BAD = Broken As Designed (cassé comme prévu)
UPDATE : Un vieil essai sur cette non-solution à un non-problème .
C'est presque la même chose que de demander "pourquoi utiliser des paquets pour Java/C#" :
Le plus grand piège, à mon avis, est l'interaction humaine dans l'interprétation des documents, par exemple le développement d'un code pour traiter un document XML. Il est trop facile de se concentrer sur l'expression littérale du document plutôt que sur l'ensemble des informations résultant de l'analyse du document.
Par exemple, les nœuds suivants
<a xmlns="uri:foo"/>
<foo:a xmlns:foo="uri:foo"/>
<bar:a xmlns:bar="uri:foo"/>sont tous sémantiquement identiques - et pourtant très différents pour l'œil naïf.
Le premier exemple présente une erreur très fréquente dans le développement des XPaths : il ne tient pas compte du fait que "a" se trouve dans un espace de noms - donc //a ne donne aucune correspondance. (ou pire encore, faire correspondre des nœuds dans un espace de nom différent !)
Le 3ème exemple ouvre une autre faille dans la compréhension - que le texte du préfixe est sémantiquement significatif. Lors de l'analyse syntaxique de documents avec XPATH, je peux déclarer n'importe quel préfixe pour la correspondance, tant que son uri correspond à celui du document.
Considérez-les comme des noms de famille pour les types d'éléments. Si vous avez deux amis qui s'appellent tous deux Bob et que vous parlez de l'un d'eux, quelqu'un pourrait vous demander de quel Bob vous parlez. Dire simplement "Bob" n'est pas très utile, alors vous dites "Bob Smith", ou "Bob Jones".
Il en va de même pour les types d'éléments. Parfois, un nom court ne suffit pas, car différentes personnes peuvent choisir le même nom. Il faut donc inclure un URI comme "nom de famille", pour distinguer les différents Bob qui existent.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
