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.


Que cache REX (Remote Events for XML)?

Répondez à cet article.

Le W3C vient de publier la première version de travail de REX (Remote Events for XML). Que cache cette spécification?

Eric van der Vlist, Dyomedea (vdv@dyomedea.com).
mardi 14 février 2006

Les groupes de travail W3C  SVG et Web API publient conjointement une première version de travail de "Remote Events for XML (REX) 1.0" ainsi de le cahier des charges de cette spécification.

REX définit une sérialisation XML des évènements décrits par DOM Level 3.

Son éditeur, Robin Berjon, répond à mes questions.

vdV: Les évènements de DOM Level 3 mentionnés dans cette première version de REX décrivent des mises à jour à apporter à un arbre DOM. REX est-il donc un langage de modification de documents XML?

RB: REX permet de transmettre des évènements et la prochaine version décrira comment transmettre tous les évènements de DOM 3 Events ainsi que des évènements « custom ». Cela peut permettre par exemple de simuler un clic sur un document distant, de synchroniser des interactions, mais ça donne aussi un langage commun permettant à des modalités d'interaction de communiquer de façon plus simple, et à tout un tas d'autres choses (comme les « remote UIs » sur lesquelles travaille IETF Widex).vdV: Pourquoi avoir limité la première version aux évènements de mise à jour (mutation events)?RB: Parce que le besoin est pressant (et aussi parce que je veux faire des petites spécifications indépendantes qui évoluent pas à pas au lieu de mettre tout et son contraire dans la première version).

vdV: Que voulez-vous dire par « besoin pressant »?

RB: Outre le fait que ce qui nous est demandé aujourd'hui par l'industrie mobile est principalement les updates (et qu'on en profite pour faire avancer une specification plus générique), il est plus difficile d'encoder les mutation events que, par exemple, les mouse events, d'où une utilité technique à commencer par là.vdV: Est-ce que REX peut être vu comme une manière de contourner le fait que XQuery ne permette pas pour le moment de mettre à jour des documents?

RB: REX ne veut pas concurrencer XQuery Udpates : XQuery Updates donne des moyens programmatifs pour mettre à jour un arbre, mais ne parle pas de la transmission dans le cas où l'arbre en question n'est pas sur la même machine. REX pourrait être un format de transmission pour XQuery Updates, et donc ne vient pas tant combler une lacune de XQuery qu'en complémenter une implémentation possible.

vdV: Je n'ai pas suivi de près les proposition d'update pour XQuery, mais j'imagine qu'il devrait être possible d'insérer des résultats d'expressions (comme en SQL) par exemple pour incrémenter un compteur et j'ai l'impression que REX ne permet d'insérer que des noeuds "constants". Dans ce cas, REX pourrait éventuellement être une sérialisation pourtransférer le résultats de mises à jours XQuery (quand XQuery le permettra) mais pas une sérialisation des requêtes elles-mêmes.

RB: C'est exactement ce que je voulais dire. L'utilité est limitée, je pointais juste ce détail pour montrer que le rapport avec XQuery est en fait relativement distant.

vdV: XUpdate semble être au point mort, REX peut-il en être un concurrent?

RB: Oui, mais le cas d'usage principal n'est pas les bases de données mais plutôt le push de mise à jour à des clients (notamment mobiles).

vdV: Effectivement, et cela semble intéressant également pour diminuer les flux d'échange dans les applications AJAX. Il doit être assez facile d'en réaliser une implémentation de référence, non?

RB: Il y a toujours des détails un peu embêtants, mais a priori ça doit pas être la mort non. Je compte en faire une assez rapidement en Perl pour pouvoir entamer les tests et vérifier que la spec est cohérente et implémentable.

Références

  1. Remote Events for XML (REX) 1.0 – Version de travail W3C
  2. Cahier des charges REX 1.0 – Document W3C
  3. Document Object Model (DOM) Level 3 Events Specification – Version de travail W3C
  1. WIDEX (Widget Description Exchange Service) – Draft IETF
  2. XQuery Update Facility – Version de travail W3C
  3. XUpdate – Spécification « XML:DB initiative »

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