D'un côté, nous avons le W.3.C, lancé depuis 10 ans dans une logique de "tout xml", notamment avec X.H.T.M.L 2.0 qui doit clore la période de transition H.T.M.L/X.H.T.M.L 1.0 en proposant une véritable rupture technologique en fusionnant définitivement application web et document web.

De l'autre, trois acteurs majeurs de l'internet, Mozilla, Opera et Apple, qui partant du triple constat que X.H.T.M.L 2.0 est encore très lointain, souffre de ne plus assurer la rétro-compatibilité et n'obtient pas le consensus cher au W.3.C, notamment par l'attitude plus que sceptique de Microsoft. Ils proposent une évolution de H.T.M.L 4.0 afin de pallier, dès maintenant, les nombreuses carences de ce langage.

H.T.M.L et sa transcription X.H.T.M.L souffre, en effet, de n'être qu'un langage de description, sans aucune possibilité de traitement applicatif, ce qui pose d'énormes problèmes à l'heure où le navigateur web devient de plus en plus une véritable plateforme applicative.

Le problème est assez compréhensible en prenant comme exemple la gestion des formulaires, sur laquelle se concentre le débat X.H.T.M.L 2.0 Vs H.T.M.L 5.

En effet, dans le langage H.T.M.L, il n'existe pas de processus natif pour assurer les traitements basiques qu'on serait en droit d'attendre pour un formulaire comme le typage des données, la validation ou la mise à jour automatique de listes de choix. On est obligé, actuellement, de déporterce processus sur des traitements de script, généralement en javascript, avec tous les problèmes inhérents à cette méthode.

A cet épineux problème, la réponse du W.3.C s'appelle XForm, un module X.M.L , intégrable dans X.H.T.M.L 2.0, mais pas dans H.T.M.L ou X.H.T.M.L 1.0; il offrirait une véritable couche applicative de traitement des formulaires, permettant à peu près tout.

Problème : il faut, préalablement, un renouvellement complet des navigateurs et que l'ensemble des acteurs trouve un consensus sur l'implémentation de X.H.T.M.L 2.0 qui est jugé "très difficile" par les éditeurs de navigateurs et vis à vis de laquelle Microsoft, qui pèse du poids qu'on lui connait, adopte une attitude très négative qui, si elle n'évolue pas, condamne, de fait, X.H.T.M.L 2.0.

Solutions : Webform, une spécification créée par le W.H.A.T.W.G permettant de reprendre certains éléments de Xform, facilement implémentable, compatible avec H.T.M.L et les navigateurs actuels. Avec Webform, on peut, par exemple, valider un champs de formulaire contenant un nombre, simplement par la déclaration de deux attributs min et max, le navigateur se chargeant de gérer le message d'alerte et la gestion de l'erreur.

Au delà de ce simple problème, H.T.M.L 5.0 devrait accueillir d'autres balises permettant de générer des grilles de "tableurs" et d'autres éléments qui manque cruellement actuellement.

Mais hélas, cela reviendrait à entériner l'échec de X.H.T.M.L 2.0 qui est un point crucial de la stratégie du W.3.C et à faire perdurer le format H.T.M.L qui même "évolué" n'en conserverait pas moins le désavantage de ne pas être un langage X.M.L.

De fait, le W.H.A.T.W.G prend le parti d'entrer en concurrence frontale avec le W.3.C et prend le risque de relancer une guerre des standards de sinistre mémoire.

Par ailleurs, comme l'explique très bien Eric Van der Vlist sur x.m.l.org, l'autre risque est de produire un langage H.T.M.L "verbeux" avec énormément de balises spécifiques alors que l'objet de la stratégie du W.3.C avec X.M.L et X.H.T.M.L 2.0 est de débarasser le langage des balises "sémantiques", donc de le simplifier à outrance aux seules balises de structures, la sémantique étant reportée sur des mécanismes dédiés.

Là où H.T.M.L 5 multiplierait les balises dédiées, X.H.T.M.L 2.0 n'offre que des balises très génériques en proposant des mécanismes sémantiques sous forme d'espace de nom ou d'attribut comme "property"permettant de relier l'élément à un identifiant sémantique.

Il s'agit donc bien de deux visions très différentes: l'une étant d'enrichir le vocabulaire, au risque de le rendre difficilement maitrisable, l'autre de le simplifier, de s'attacher à la seule structure et de donner du sens par des mécanismes venant se greffer sur le vocabulaire de base.

Il est très difficile de savoir quel peut être l'avenir de cette proposition qui a pour elle d'être assez facilement implémentable, d'être soutenue par trois acteurs majeurs, engagés dans des politiques d'innovations permanentes et de s'appuyer, in fine, sur le langage dominant et donc de trouver certainement une oreille attentive auprès des développeurs et des webmasters qui éviterait ainsi l'apprentissage d'un nouveau langage, de nouveaux concepts et de méthodes de développement radicalement différentes.

Le W.A.T.H.W.G a émis une note auprès du W.3.C sur cette proposition, première étape pour engager, éventuellement, une collaboration plus étroite et tenter de convaincre le W.3.C de la pertinence de cette spécifications.

Parallèlement, les fonctionnalités de H.T.M.L 5 vont sans doute être implémentées en tant que format propriétaire par les produits des membres du W.H.A.T.W.G, ce qui n'est pas sans nous rappeler une période que l'on croyait définitivement révolue.

Affaire à suivre, mais on peut d'ores et déjà dire que H.T.M.L 5 est le premier véritable échec de la normalisation en cours, en tout cas telle qu'elle avait été "programmée" par le W.3.C

Pour en savoir plus

• Le site du W.H.A.T.W.G (en anglais)
• L'excellent article sur x.m.l.org
• Une présentation claire de WebForm sur le journal du net
  
• La rapide analyse de Tristant Nitot sur le standblog