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 2001
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.
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.
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.
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.
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.
|
