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.
 Manifestations XML francophones et internationales.L'actualité des affaires et stratégies XML.L'actualité des technologies XML.Les nouveautés et l'actualités de notre site.Pointeurs sur l'actualité XML sur d'autres sites, en français comme en anglais.


Cinq défis pour XML

Répondez à cet article.

Premier lauréat de la Coupe XML  IDEAlliance et orateur de la session plénière d'ouverture de XML 2001, James Clark décrivit de manière vivante et détaillée les cinq défis auxquels fait face la communauté XML et fournit ainsi la clé nécessaire pour comprendre plusieurs annonces faites depuis cette date.

Eric van der Vlist, Dyomedea (vdv@dyomedea.com).
mardi 18 décembre 2001James Clark

1) Progresser sans compromettre la force de XML

Affirmant que la principale force de XML est sa diversité XML "couvre tout depuis l'encodage d'appels de procédures SOAP ayant une durée de vie de quelques millisecondes jusqu'à l'encodage de textes sacrés bouddhistes à la durée de vie de millénaires" et qu'elle vient de sa simplicité: "XML ne fait pas grand chose en lui-même, ... pour moi XML n'est qu'une syntaxe pour encoder des arbres nommés", James Clark nous enjoint à conserver cette simplicité et cette universalité en "séparant les fonctionnalités d'intérêt général ne s'intéressant qu'à cet arbre nommé de celles de plus haut niveau qui sont spécifiques à un domaine particulier, que ce soit les bases de données, les documents, les services web ou n'importe quoi" et il cite comme mauvais exemples les types "date" de W3C XML Schema et son attribut xsi:nill.

James Clark

2) Ne pas négliger les fondations.

Tant d'applications reposent maintenant sur XML que ses fondations devraient être "solide comme le roc" et James Clark encourage à "passer un peut de temps à réparer les bases". Parmi les choses à réparer, il cite XML 1.0 "bizarre" parce que spécifiant "qu'il faut transmettre les références aux entités externes non parsées mais pas qu'il faut transmettre les éléments et attributs",  les espaces de noms, XML Infoset et XML Base qui devraient être intégrés à la spécification de base et les DTDs qui sont "dans le fond un gros gâchis", mélangent trop de fonctions différentes sous une syntaxe non XML et dont nous ferions mieux d'apprendre à nous passer et les entités caractères pour lesquels une solution de rechange doit encore être trouvée.

James Clark

3) Trouver les pièces qui manquent

Le modèle de traitement devient de plus en plus complexe et intègre maintenant la validation, les inclusions, les transformations et bientôt la gestion des requêtes. Il manque une solution globale pour définir et "contrôler le pipeline de traitements". Chaque fonction tente de résoudre le problème à sa manière (doctype, xsi:schemaLocation, stylesheet location, …), sans qu'aucune d'entre elles ne "marche terriblement bien" et James Clark considère qu'il y a là un manque majeur.

James Clark

4) Améliorer le traitement de XML

Notant que les solutions actuelles pour traiter les documents XML sont "trop de travail, trop difficiles, trop sujettes à erreur",  James Clark souhaite que les outils de traitements soient améliorés, qu'il s'agisse d'API utilisés par des langages classiques ou de langages spécifiques à XML:

Si vous utilisez un langage de programmation générique pour traiter du XML, il vous manque un "API standard en mode pull" avec des readers et des writers comme celle de .Net ("ce n'est pas parce que cela vient de Microsoft que c'est nécessairement mauvais") et des API de data binding faiblement couplées qui "automatisent le processus de correspondance entre le XML et les modèles de données", y compris lorsque ce modèle est basé sur des graphes et non des arbres.

Si vous utilisez un langage de traitement spécifique à XML, XSLT est aujourd'hui le choix le plus répandu, mais XSLT est "utilisé pour des choses vraiment effrayantes" et il lui manque un système de typage de données qui lui permette de détecter les erreurs. Nous avons donc besoin d'un "meilleur langage spécifique à XML" et "XQuery est prometteur" à ce niveau.

James Clark

5) Eviter la standardisation prématurée

Remarquant que d'"avoir un standard n'est pas toujours une bonne chose" et qu'une "standardisation trop hâtive peut couper les ailes à l'innovation" en empêchant les petites organisations d'inventer de meilleures solutions au point qu'un standard peut parfois devenir une arme anti-concurrentielle, James Clark nous demande de luter contre la standardisation prématurée. Et, puisque "beaucoup de gens acceptent les standards à l'aveuglette", "les gens doivent appliquer les facultés critiques aux standards". Il note également que "tout n'a pas besoin d'être standard" et donne l'exemple des solutions pour traiter des documents XML qui contrairement aux documents n'ont pas besoin d'être standards. Aux développeurs soucieux d'éviter d'être captés par un éditeur de logiciel; James Clark rappelle que l'open source peut être une solution aussi efficace que les standards.

Autres articles:

Copyright 2001, 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