Accueil
 chercher             Plan du site             Info (English version) 
L'histoire de XML s'écrit en ce moment même. XMLfr vous aide à la suivre et à en dégager les tendances.Les listes de discussions XMLfr sont à votre disposition pour réagir sur nos articles ou simplement poser une question.Si vous ètes passionnée(e) par XML, pourquoi ne pas en faire votre métier ?XMLfr n'est heureusement pas le seul site où l'on parle de XML. Découvrez les autres grâce à XMLfr et à l'ODP.Les partenaires grâce auxquels XMLfr peut se développer.Pour tout savoir sur XMLfr.XMLfr sans fil, c'est possible !Pour ceux qui veulent vraiment en savoir plus sur XML.L'index du site.
 Si vous vous posez une question, vous n'êtes peut-être pas le premier...Les traductions en français des bibles XML.Ces articles sont des références dans leur domaine.Tout ce qu'il faut savoir pour démarrer sur un sujet XML...


XP et XML

Quelles relations peut-il y avoir entre des concepts de natures différentes tels que XP (eXtreme Programming) et XML (eXtensible Markup Language)? Telle était la question qui m'était posée pour la troisième édition de SparklingPoint Networking.

Eric van der Vlist, Dyomedea (vdv@dyomedea.com).
vendredi 22 novembre 2002

A part le "X" qui les rapproche dans les glossaires, quel lien peut-il bien y avoir entre XP (eXtreme Programming) et XML (eXtensible Markup Language)?

Notons d'abord que ces deux concepts ne sont pas de même nature: XP est une méthodologie de développement et donc un concept abstrait alors que XML est une syntaxe permettant de dégager la structure des documents, donc un outil. Le seul point commun à ce niveau est sans doute que la foi de leurs partisans respectifs peut parfois les faire passer pour des religions!

Les liens entre XP et XML sont donc les liens qu' il peut y avoir entre une méthodologie et un outils: l'outil peut servir à implémenter suivant la méthodologie (directement ou en permettant le développement d'ateliers adaptés à la méthodologie). La méthodologie peut s'appliquer plus ou moins bien à l'utilisation de l'outil.

Il y aurait beaucoup à dire sur le premier point: XML facilite le développement d'infrastructures communiquantes et inter-opérables et XP repose sur des communications fortes et transparentes que XML peut aider à mettre en oeuvre.

Si nous avions plus de temps, il serait intéressant de reprendre les douze pratiques XP et de regarder pour chacune d'entre elles l'apport actuel et potentiel de XML et je pense par exemple que l'utilisation d'une infrastructure communiquante (telle que le protocole XML de Jabber) pourrait faciliter la programmation de binômes à distance et lever un des obstacles à l'utilisation de XP sur des projets notamment open source où les développeurs n'ont pas la possibilité d'être réunis physiquement.

Je voudrais plutôt insister ici sur le deuxième volet et voir ce qu'il peut y avoir de particulier à utiliser XP pour développer des applications XML.

Une première catégorie de problèmes potentiels est liée au principe de "refactoring": le fait d'utiliser plusieurs technologies simultanément (par exemple un langage de programmation, un vocabulaire XML, un langage de schéma XML, un langage de transformation tel que XSLT et des feuilles de style CSS) complique ce "refactoring" et augmente l'impact de modifications qui pourraient être considérées comme mineures.

Ce problème n'est qu'une conséquence du principe de "design simple" qui peut pousser à éviter purement et simplement XML pour certaines applications simples notamment si les équipes de développement ne maîtrisent pas l'ensemble des outils XML utiles dans le cadre du projet.

Ce n'est pas spécifique à XML et le même type de problèmes se pose pour l'utilisation de technologies additionnelles (une base de données relationnelle par exemple) et c'est dans le domaine des tests unitaires qui sont une des pratiques les plus fondamentales de XP que XML va poser des problèmes de deux natures que nous allons détailler plus particulièrement ce soir:

  1. XML admet des niveaux de variations syntaxiques dépendant des applications qui rend difficile les tests d'égalité ou d'équivalence entre deux documents ou fragments XML générés par une application ou une méthode
  2. Puisque l'on introduit un langage de programmation nouveau (XSLT), il faut introduire l'outil de test unitaire adapté

Lorsque l'on écrit des tests unitaires pour tester qu'un fragment XML généré par une fonction est identique à ce que l'on attend, on est tenté de tester la sérialisation de ce fragment en comparant des chaînes de caractères.

Si on attend un élément vide "foo" avec deux attributs "bar1" égal à 1 et "bar2" égal à 2, on testera par exemple que la chaîne de caractères obtenue est <foo bar1="1" bar2="2"/>...

Le problème est alors que cet élément est réputé équivalent à <foo bar2="2" bar1="1"/> puisque l'ordre des attributs n'est pas significatif en XML ou <foo bar1='1' bar2='2'/> puisque l'on peut indifféremment utiliser des simple ou des doubles guillemets pour encadrer la valeur des attributs.

Certaines applications ne considéreront pourtant pas ces "sérialisations" comme équivalentes: si l'application que nous développons était une bibliothèque de "canonicalisation" de XML imposant des doubles guillemets et des attributs classés par ordre alphabétique, ces variations seraient significatives pour nous et nous voudrions pouvoir les tester.

Ces variations syntaxiques peuvent intervenir à des niveaux différents et dépendent de l'application comme nous le montre l'exemple précédant. La valeur du préfixe utilisé par les espaces de noms, les caractères blancs et l'ordre relatif de certains éléments sont d'autres exemples classiques de variations extrêmement dépendantes des applications.

Deux voies sont possibles pour résoudre ce problème: la première est de développer sa propre "canonicalisation" dépendant de l'application considérée et de comparer systématiquement les formats "canonicalisés" sous forme de chaînes de caractères. La deuxième est de comparer non pas les "sérialisations" des fragments XML mais les arbres DOM ou les flux d'évènements SAX avec une librairie adaptée à cet usage.

C'est un des problèmes que j'ai rencontré lors du développement de mon implémentation Python des "Regular Fragmentations" et la recherche que j'ai fait à cette époque (juillet 2002) m'a montré que s'il existait de nombreuses bibliothèques pour effectuer ce type de comparaison d'arbres, ces bibliothèques étaient très orientées "édition de document", permettaient souvent de reconstituer un document à partir d'une version et des différences entre deux versions mais ne permettaient pas de paramétrer finement les tests à effectuer pour considérer que des fragments sont "équivalents" et ne présentaient pas souvent le résultat des comparaisons sous une forme facilement lisible.

J'ai donc développé une bibliothèque très simple qui fait les tests dont j'avais besoin pour cette implémentation et pourrait servir de base au développement d'une bibliothèque plus complète.

Il y a là un problème qu'il ne faut pas sous-estimer et je pense que d'autres bibliothèques de ce type devraient être développées ainsi que des outils permettant de définir la canonicalisation à appliquer sur un document.

Le deuxième point concerne les tests unitaires sous XSLT. Dans la mesure où XSLT est un langage de programmation complexe, il est indispensable pour rester fidèle aux pratiques XP de pouvoir tester unitairement les "templates" XSLT (qu'ils soient nommés ou non) et j'ai développé, sur le modèle des environnements de tests unitaires classiques, XSLTUnit.

Ces deux points sont d'ailleurs liés: XSLTUnit effectue la comparaison entre un arbre attendu et l'arbre généré et il faudrait que cette comparaison puisse elle aussi être paramétrée pour définir quels sont les tests à effectuer, ce qui n'est pas le cas dans ma première version.

Autres articles:

Copyright 2002, Eric van der Vlist.


 

Mots clés.



L'histoire de XML s'écrit en ce moment même. XMLfr vous aide à la suivre et à en dégager les tendances.


Les documents publiés sur ce site le sont sous licence "Open Content"
Conception graphique
  l.henriot  

Conception, réalisation et hébergement
Questions ou commentaires
  redacteurs@xmlfr.org