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.


XML 2006 : souvenirs, souvenirs

Répondez à cet article.

La conférence XML 2006 a été marquée par le dixième anniversaire de XML, la vivacité du Web 2.0 et la promesse de l'arrivée prochaine de XQuery.

Eric van der Vlist, Dyomedea (vdv@dyomedea.com).
mercredi 13 décembre 2006

Table des matières

La conférence du dixième anniversaire

Web

Génération d'interfaces XForms

Signature de documents avec XForms

JSON est le X dans AJAX

XQuery au secours des éditeurs

Yahoo! et la conception d'applications Web 2.0

Web 2.0 et XML

Utilisation de XML sur des « petits » terminaux

Les « petits » terminaux en font parfois plus que les grands

L'arrivée attendue de XQuery

Autres sujets

Publication

W3C Schemas for Databinding

Langages de pipelines

APIs XML

Références

Couverture de la conférence XML 2006

La conférence du dixième anniversaire

David Megginson a donné le ton dès son discours de bienvenue : XML 2006 serait la conférence du dixième anniversaire de XML. La première version de ce qui allait devenir la recommandation W3C XML 1.0 a en effet été présentée en 1996, lors de cette conférence (qui s'appelait alors SGML 96) organisée dans le même hôtel.

On notera que SGML 96 se définissait elle-même comme la conférence du dixième anniversaire de SGML et que XML 2006 marquait donc le vingtième anniversaire de la saga SGML.

Trois des membres du groupe de travail W3C SGML qui ont participé à la rédaction du document présenté à SGML 96 étaient dans la salle et David Megginson a appelé sur scène Jon Bosak, C. M. Sperberg-McQueen et Jean Paoli qui furent copieusement ovationnés.

Le ton était donné : XML 2006 allait être la conférence du dixième anniversaire de XML avec avec son lot de nostalgie et de questionnement : dix ans déjà! où sont passés les autres protagonistes de ce document qui sont pourtant des habitués des conférences XML? XML en serait-il arrivé au même point que SGML en 96?

La conférence était divisée en quatre sessions parallèles ayant pour thèmes l'édition (publishing), le Web, l'entreprise et la pratique (hands-on). La plupart des présentations concernant les technologies de base XML qui m'attirent d'habitude étaient réparties entre les deux derniers de ces thèmes. A la lecture du programme, il m'a semblé que les nouveautés se concentraient au contraire dans les sessions concernant le Web et c'est ce thème que j'ai privilégié dans mes choix de programme.

Web

Génération d'interfaces XForms

J'ai l'habitude de souligner l'opposition entre XForms et les autres méthodes de développement Web en qualifiant XForms d'approche déclarative. Dans sa présentation intitulée « The Essence of Declarative, XML-based Web Applications: XForms and XSLT », Chimezie Ogbuji a montré comment l'utilisation de XSLT pouvait rendre le développement avec XForms si ce n'est plus déclaratif du moins plus haut niveau.

Certains contrôles XForms sont assez bas niveau et il peut être intéressant de définir des contrôles de plus haut niveau pour accélérer les temps de développement mais également pour garantir la cohérence de ces contrôles lorsqu'ils sont répétés à plusieurs endroits.

Pour cela, Chimezie Ogbuji a défini un sur ensemble de plus haut niveau à XForms qui est transformé par XSLT avant publication.

Voulant éviter de réinventer la roue, ce sur ensemble fait appel à des éléments XUL lorsque c'est possible. Les documents sources sont donc des documents composites mélangeant XHTML, XForms, XUL et un vocabulaire maison pour les contrôles haut niveau qu'il n'a trouvé dans aucun des autres vocabulaires.

Autre intérêt de ce mécanisme, la transformation peut masquer les problèmes d'interopérabilité encore fréquents entre implémentations XForms.

Signature de documents avec XForms

Quel problème spécifique peut-il y avoir à utiliser XML Signature avec XForms? Outre les aspects purement techniques posés par la définition d'un module XForms pour XML Signature, John Boyer a couvert dans sa présentation « Applying XML Signatures to XForms-based Documents » le problème de principe de toute signature électronique qui est de « signer ce que l'on voit » (« what you see is what you sign »).

Dans la mesure où XForms permet justement de découpler les documents XML manipulés de leur présentation à l'écran, il y a un paradoxe à utiliser XForms pour signer un document XML que l'on ne voit pas.

La solution proposée est de signer non pas uniquement les fragments du document XML édités par l'utilisateur mais également les éléments techniques utilisés pour afficher la page (y compris la page XForms elle-même et les feuilles de style CSS utilisées).

En tant qu'utilisateur, cela ne vous permet pas de vérifier sur quoi porte la signature que vous apposez au moment où vous signez, mais en cas de contestation de votre part, le site ne pourra prouver que vous avez réellement vu ce que vous avez signé que s'il a inclus ces éléments techniques.

Ceci dit, tout cela semble néanmoins reposer sur la confiance que vous avez dans l'implémentation XForms qui vous demande d'apposer votre signature. Si l'on peut admettre que vous faites confiance au navigateur Web que vous utilisez et auquel vous confiez déjà vos mots de passe et numéro de carte de crédit, le dispositif devrait fonctionner avec une implémentation native de XForms telle que celle de Mozilla. On peut par contre se demander quel niveau de confiance accorder à une implémentation sous forme de plugin ou à une implémentation serveur de XForms.

JSON est le X dans AJAX

La présentation de Douglas Crockford, « JSON, The Fat-Free Alternative to XML » pouvait faire figure de provocation dans une conférence XML, surtout après l'hommage appuyé de Simon St.Laurent, président de session qui avait annoncé cette présentation comme une des plus importantes de la conférence.

La présentation, à laquelle assistaient nombre d'experts XML dont Jon Bosak, n'a pourtant pas suscité de remous et Douglas Crockford a pu dérouler son argumentaire en faveur de JSON dans le calme.

JSON n'est autre qu'un sous ensemble de JavaScript limité à la définition de littéraux. Douglas Crockford a souligné la simplicité de JSON comparé à XML et aux technologies associées. Le typage, les schémas et les espaces de noms étaient tout particulièrement dans sa ligne de mire : selon lui, le typage a « un bénéfice limité » pour les applications Web, les schémas ne sont pas très utiles et les espaces de noms une complication inutile.

S'il est vrai que les exemples proposés par Douglas Crockford sont simples, il faut tout de même remarquer que ni le typage, ni les schémas ni les espaces de noms ne sont obligatoires en XML mais que ce sont des options qui peuvent être utilisées si elles se justifient.

De plus, les APIs de data binding modernes permettre de générer automatiquement des documents XML à partir d'objets et des objets à partir de documents XML. Il est donc possible de transmettre des objets entre un serveur et un client JavaScript de manière aussi simple avec XML qu'avec JSON.

Douglas Crockford a également clairement indiqué que JSON n'est adapté qu'à l'échange de données et n'est pas un format de document. On peut s'interroger de la pertinence d'une telle distinction sur le Web. Même en prenant un exemple aussi classique que la transmission d'un cours de bourse pour laquelle JSON semble tout indiqué, il suffit de vouloir permettre d'ajouter un lien ou des indication de mise en page dans une description pour introduire un contenu mixte facile à exprimer en XML et hors du champ de JSON.

Il me semble donc que la simplicité de JSON est avant tout une question de perception.

XQuery au secours des éditeurs

La présentation la plus réussie de la conférence a été à mon sens celle de Jason Hunter,

« Web Publishing 2.0 and XQuery ». Contrairement à ce que pouvait laisser supposer ce titre, il ne s'agissait pas vraiment de XQuery mais plutôt de donner des exemples concrets de ce que des éditeurs de livres peuvent faire pour proposer des fonctions qu'ils sont les seuls à pouvoir proposer parce qu'ils ont accès au balisage de leurs textes.

On pourrait résumer son intervention par le titre d'une de ses pages : « exploitez la structure de vos documents XML pour battre Google » mais se serait passer à côté des dizaines d'exemples concrets et des anecdotes qui ponctuent son exposé.

Pour Jason Hunter, les utilisateurs cherchent des réponses et non des liens et c'est le premier domaine dans lequel la connaissance du balisage des textes peut vous permettre de briller. C'est particulièrement vrai dans le domaine de l'édition technique ou scientifique où ce balisage permet souvent d'extraire les définitions des concepts recherchés.

A côté de cela, il détaille d'autres fonctionnalités qui permettent de rendre votre contenu plus appétissant (« sweat the content ») et de créer plus de contenu avec les mêmes sources : micro-contenus, publication à la demande, jeux, ...

Il insiste sur les rapports ambigus entre Google et le monde de l'édition et sur le fait que, plutôt que d'avoir peur de Google, les éditeurs devraient chercher à faire mieux que lui et à l'utiliser. Faire mieux que lui revient, et c'est son leitmotiv, à exploiter la connaissance de la structure des documents. Pour l'utiliser, on pourra par exemple se baser sur les recherches effectuées sur un site pour optimiser l'achat de publicités sur Google ou encore réaliser des « pages d'atterrissage » personnalisées.

Il détaille également les aspects plus classiques du Web 2.0 et tout ce qui permet de transformer ses visiteurs en acteurs. Outre les fonctions de blog, commentaires et tagging, il insiste sur la nécessité de tirer partie de l'intelligence collective d'opérations aussi simples que les recherches. Saviez-vous que la fonction « Essayez avec cette orthographe » de Google n'est pas basée sur un dictionnaire mais sur l'analyse des recherches effectuées par les utilisateurs? Transformer ses utilisateurs en acteurs passe également par des fonctionnalités personnalisées telles que la possibilité de rechercher dans sa bibliothèque personnelle (un moyen de donner envie aux utilisateurs de vous dire quels livres ils possèdent...). Et ces fonctionnalités personnalisées sont également très prometteuses dans le domaine de l'apprentissage.

Revenant sur l'exploitation de la structure des documents, il montre ensuite comment cela peut non seulement permettre de trouver une aiguille dans un tas de foin mais également de « trouver le tas de foin » en donnant une vue globale et statistique sur une collection de documents.

Sa conclusion est que nous ne sommes qu'au début du Web 2.0, cherchons encore notre voie et que pour réussir sur le Web, les éditeurs doivent se montrer agiles dans la conception de leurs sites, leur développement et leurs modèles économiques.

Yahoo! et la conception d'applications Web 2.0

Dan Theurer a présenté, sous le titre « What Powers Web 2.0 Mashups » les ressources mises à la disposition des développeurs d'applications Web 2.0 par Yahoo! et ses filiales.

Il insiste sur le caractère complet de cette offre gratuite pour les applications non commerciales et qui comprend :

  1. l'accès aux données via des API web,
  2. une documentation de qualité,
  3. des outils, avec notamment la Yahoo! User Interface (YUI) library,
  4. le support technique au moyen de listes de discussions.

Certaines applications Web 2.0 accèdent à des informations personnelles stockées sur les services de Yahoo! ou de ses filiales et cela pose des problèmes de sécurité. Dan Theurer a donc détaillé les fonctions d'authentification mises en place par Yahoo!. Ces fonctions permettent:

  1. de s'identifier sur Yahoo! pour autoriser une application Web à accéder à ses données personnelles
  2. une gestion de type « single sign in » permettant de s'identifier sur Yahoo! pour accéder à des fonctionnalités personnalisées de sites partenaires.

Web 2.0 et XML

La table ronde « Web 2.0 and XML » a réuni Elliotte Harold, Simon St. Laurent, Jason Hunter, et moi-même (Eric van der Vlist) pour débattre des liens entre Web 2.0 et XML.

Simon St.Laurent a une vision assez négative du succès de XML en tant que « SGML sur le Web » et il n'hésite pas à parler d'échec à propos de la vision initiale qui a motivé la création de XML. Cette vision tendait à remplacer SGML par un triptyque XML/XSL/XLink rendant n'importe quel document XML utilisable dans un navigateur Web. Pour Simon St.Laurent, cette utilisation reste marginale et XLink n'a pas réussi à s'imposer ce qui rend le triptyque bancal.

Jon Bosak qui assistait à ce débat n'a pas pris la parole. Il semble néanmoins moins négatif puisque j'ai eu l'occasion de l'entendre dire lors d'un dîner que la spécification UBL publiée au format XML  DocBook s'affichait parfaitement bien dans les navigateurs Web et qu'il y voyait au contraire l'aboutissement de la vision « SGML sur le Web ».

Autre point de vue, celui de Jason Hunter pour qui, au contraire, nous n'avons jamais vu autant de XML sur le Web que depuis le développement du Web 2.0.

Elliotte Harold a préféré prendre part au débat « JSON ou XML? » en faisant un vibrant plaidoyer pour XML seul format permettant de fédérer plusieurs utilisations qui m'a rappelé la présentation « Pourquoi XML? » que j'ai donné en 2001.

J'ai publié la position que j'ai exprimé lors de cette table ronde sur mon carnet web sous le titre : « Why XML Experts Should Care About Web 2.0 ». Je pense que XML est arrivé à un stade de maturité où il lui est difficile d'évoluer : la difficulté avec laquelle XML 1.1 qui est pourtant une évolution relativement mineure cherche à s'imposer en est une preuve. Après dix ans de XML on est arrivé à un stade similaire à celui de SGML en 96 après dix ans de SGML.

L'évolution de l'informatique passe par une phase d'innovation et bien que nous manquions de recul pour l'affirmer, le Web 2.0 fait vraisemblablement partie de cette phase d'innovation. Le succès de XML en tant que « SGML sur le Web » n'est pas acquis et nous avons sans doute besoin d'une nouvelle itération pour mettre « XML sur le Web ».

Il est également trop tôt pour savoir ce qu'il sortira de cette phase d'innovation qui remet en cause certaines des technologies que nous utilisons actuellement, mais s'il a fallu accepter de changer SGML pour le mettre sur le Web, peut-être sera t-il nécessaire de changer XML pour qu'il finisse de s'imposer sur le Web.

Utilisation de XML sur des « petits » terminaux

David Lee a présenté sous le titre « XML encoding techniques for storing XML data on memory limited » une technique pour utiliser XML sur des terminaux disposant de peu de mémoire.

La première partie de son exposé décrit l'univers de ces terminaux, assistants personnels et téléphones portables. Il cherche notamment à montrer que contrairement à ce qui se passe pour les ordinateurs portables ou de bureau, la puissance et la taille mémoire des petits terminaux n'augmentent pas, ou plutôt que cette augmentation ne concernent que le haut de gamme qui ne représente qu'une niche sur le marché global de ces terminaux.

Pour la majorité de ces terminaux, les progrès techniques sont en effet compensés par la baisse des prix de ventes et les performances augmentent peu d'une génération à l'autre.

David Lee travaille pour Epocrates, une société qui conçoit, met en place et exploite des applications utilisant des assistants personnels dans le monde médical. L'utilisation de XML sur ces terminaux pose des problèmes de taille mémoire et de puissance de processeur qui ont été résolus en parsant les documents XML sur le serveur et en envoyant aux terminaux le résultat de ce parsing sous un format binaire. Leur système permet également de compresser le texte contenu dans les documents les plus volumineux.

Bien que ce type de système soit désormais classique, l''exposé était clair et présentait bien les enjeux de ce type d'optimisation.

Les « petits » terminaux en font parfois plus que les grands

Sous son titre ironique (« Honey, I Shrunk the Kids: XML on the Mobile Web »), la présentation de Michael Smith et Rocco Georgi promettait d'être très « bleeding edge » puisque Michael Smith avait prévu de faire sa présentation à partir d'un mobile de toute dernière génération disposant d'une interface Wifi et d'une sortie vidéo!

Des drivers Wifi manquant de stabilité doublés d'un problème de connectique ont eu raison de ce projet ambitieux et les orateurs ont du se rabattre sur un PC qui n'a accepté de se connecter au vidéo projecteur qu'avec beaucoup de difficultés...

Michael Smith a donc fait presque tout son exposé de mémoire et sans support ce qui est une belle performance. Son message principal est qu'il ne faut pas considérer les « petits terminaux » et notamment les téléphones mobiles comme des ordinateurs auxquels il manque quelque chose mais qu'au contraire, ils ont souvent des possibilités qui manquent aux ordinateurs.

Ses exemples proviennent essentiellement du Japon où il réside et qui est en avance dans ce domaine. Les téléphones mobiles Japonais sont équipés de GPS et Michael Smith a décrit ses applications préférées qui allient Web 2.0 et GPS.

Lorsque Rocco Georgi a réussi à faire fonctionner son ordinateur, il a fait le point sur le support d'Ajax sur les téléphones portables, soulignant que les choses avaient tendance à s'arranger avec chaque nouvelle version mais qu'il était beaucoup plus difficile de développer des applications fonctionnant sur tout les mobiles que de développer des applications fonctionnant sur tout les ordinateurs portables ou de bureau.

L'arrivée attendue de XQuery

En dépit de l'attrait du thème « Web », la technologie phare de XML 2006 aura été XQuery.

Deux facteurs expliquent cet intérêt : les spécifications XQuery devraient être prochainement promues au rang de recommandation W3C ce qui est une preuve de stabilité et les grandes bases de données relationnelles (Oracle, DB2, Microsoft  SQL Server) supportent maintenant XQuery.

Les mauvaises langues suggèrent que cette synchronisation n'est peut être pas l'effet du hasard mais la coordination de ces deux facteurs justifient l'intérêt pour une technologie qui sera d'ici peu à la fois stable et utilisable dans les bases de données les plus réputées.

Cela traduit également un changement de perspective assez radical. Longtemps considéré comme un format d'échange, XML est maintenant vu comme un format de stockage. Une des présentations s'intitulait d'ailleurs « la résistance est futile : vous stockerez du XML ». Son auteur travaille pour IBM.

Les deux tutoriels « XML and Databases » et de « XQuery 1.0, XPath 2.0, and XSLT 2.0 Explained » ont fait salle comble et la session plénière d'ouverture s'intitulait « Getting There — The XML/XQuery Ecosystem ». De nombreuses présentations portaient également sur XQuery et les bases de données XML ont indéniablement été le sujet chaud de la conférence.

Autres sujets

J'ai délaissé le thème du « Web » à trois reprises.

Publication

En tout début de conférence, j'ai suivi la session « Peaceful coexistence: The SGML/XML Transition at Cessna Aircraft » et la table ronde XML Project Management Best Practices and Case Studies qui l'a suivi.

En fait de coexistence pacifique, la présentation détaillait les principaux points techniques observés lors de la migration de SGML vers XML chez Cessna. Une manière de prouver, si vous en doutiez encore, que XML est suffisamment mur pour détrôner SGML dans les plus lourdes de ses applications.

La table ronde fut l'occasion de rappeler qu'il faut concevoir un système XML en fonction des informations qu'il représente et non en fonction de la présentation à obtenir (Kate Hamilton) mais également que les projets XML comme les autres dépendent avant tout des personnes qui les mettent en œuvre.

Mike Sherlock a insisté à plusieurs reprises sur l'importance de s'assurer que les membres d'un projet se comprennent et a souligné l'utilité des cas utilisateurs (use cases) même informels.

Sarah O'Keefe a enfoncé le clou en affirmant que si l'on peut réussir un projet en dépit de mauvais outils, un projet est voué à l'échec si ses utilisateurs ne sont pas motivés.

Proposant une classification en quatre niveaux :

  1. support papier
  2. on fait en sorte que cela soit bien présenté sous Word
  3. utilisation de templates Word
  4. XML

elle suggère qu'il n'est pas raisonnable de faire progresser des utilisateurs de plus d'un niveau à la fois.

W3C Schemas for Databinding

Ma deuxième incartade hors des sessions « Web » a été pour suivre la session sur les « W3C Schema Patterns for Databinding » et la table ronde sur les langages de pipelines.

Ces « patterns for databinding » sont en fait une tentative pour résoudre les problèmes d'interopérabilité entre schémas W3C XML Schema qui sont particulièrement important dans le domaine des outils de data binding. Si les validateurs de schémas tentent généralement d'implémenter l'intégralité des recommandations W3C XML Schema, les outils de data binding guidés par des schémas ont au contraire tendance à ne supporter que des sous ensembles de ces recommandations. Et comme ces sous ensembles sont différents, un schéma écrit pour valider des documents a peu de chances de fonctionner avec ces outils et schéma qui fonctionne avec l'un de ces outils ne fonctionne pas nécessairement avec les autres.

Pour contourner ce problème, le W3C a créé un groupe de travail charger de reconnaître des « patterns » (ou motifs) dans les schémas W3C XML Schema et de classer ces différents patterns en trois catégories :

  1. basiques (bien supportés par les différents outils de data binding)
  2. avancés (communs mais moins bien supportés par les outils de data binding)
  3. en attente (non encore classifiés par le groupe de travail)

Ces patterns sont implémentés par des expressions XPath 2.0 exécutées sur les documents XML représentant les schémas.

La démarche est intéressante, mais cette approche me semble être un peu trop primaire pour être réellement efficace : ces expressions XPath ne gèrent pas les inclusions ou imports de schémas et elles ne suivent pas les chaînes de dérivation.

Si l'on reprend un des exemples de patterns donnés lors de cette présentation, le pattern AnyURIElement correspond à l'expression :

Ce pattern ne permettra que d'identifier des définitions d'éléments dont l'attribut type est xs:anyURI mais il n'identifiera pas les éléments dont le type est dérivé de xs:anyURI. Si l'on se base sur des patterns de ce type pour mesurer les risques de problèmes d'intéropérabilité, on s'expose donc à de mauvaises surprises.

Je pense qu'il faudrait introduire l'idée une approche à deux phases : une première phase appliquerait un premier jeu de patterns sur le schéma brut tel que c'est le cas aujourd'hui et une deuxième phase appliquerait un deuxième jeu de patterns sur une version consolidée et normalisée du schéma qui permettrait de s'affranchir des problèmes d'inclusion, d'import et de dérivation.

Langages de pipelines

La table ronde sur les langages de pipelines regroupait Sam Page qui présentait en quelque sorte le portrait d'un système de pipelines idéal et Norman Walsh qui présentait les travaux du groupe de travail W3C  XProc.

Vous serez sans doute soulagés de savoir que la version actuelle de XProc couvre bien les besoins exprimés par Same Page.

Pour ma part, en tant qu'utilisateur du langage de pipelines XPL d'Orbeon dont j'ai pu apprécier la souplesse, j'ai été rassuré de vérifier que ses fonctionnalités ont été reprises dans XProc.

Cette spécification devrait donc fournir une très bonne base pour définir des enchaînements complexes de traitements à faire subir à des documents XML.

Le seul moment de flottement a été lorsqu'un spectateur a demandé quels étaient les liens entre XProc et BPEL et que Norman Walsh a répondu très diplomatiquement que cela faisait très longtemps qu'il n'avait pas regardé BPEL.

Je pense qu'il y a indéniablement recoupement entre XProc et une partie de BPEL mais que les approches sont différentes. BPEL est plus complexe et lié au contexte des Services Web. XProc est au contraire focalisé sur la définition de traitements. XProc semble également moins procédural : il n'y a pas de définition de séquences de traitements mais uniquement la définition de traitements et c'est en fonction de la manière dont sont connectées les entrées et les sorties que le séquencement des traitements est déterminé par les implémentations.

APIs XML

Ma dernière escapade hors du thème « Web » a été pour participer à la table ronde « Next-generation XML APIs » avec Elliotte Harold et Philippe Poulard.

Elliotte Harold présentait son API XOM qui est sans doute la plus moderne des APIs permettant manipuler des documents XML avec une approche DOM, Philippe Poulard présentait Active Tags, un système de programmation XML qui peut être vu comme un langage de pipelines bas niveau offrant beaucoup de contrôles sur la manière dont les traitements sont exécutés et je présentais TreeBind, mon API de binding entre objets Java, XML, RDF et LDAP.

Les trois approches étaient si différentes que nos auditeurs ont sans doute eu beaucoup de mal à faire le lien entre les trois courtes présentations qui leur ont été consacrées. L'animateur de cette table ronde a semblé aussi désemparé que les spectateurs et le débat a rapidement tourné court faute de question.

Références

  1. Conférence XML 2006
  2. The Birth of XML (Jon Bosak)
  3. Première version de travail de XML
  4. Programme de la conférence SGML 96

Couverture de la conférence XML 2006

  1. XML 2006: Day One, Day Two and Day 3 (David Megginson)
  2. Settled in at XML 2006 et Home from XML 2006 (Bob DuCharme)
  3. Café con Leche (Elliotte Rusty Harold) mardi, mercredi, jeudi.
  4. XML 2006 kicks off et XML and the Next Web (and the Previous...) (Simon St.Laurent)
  5. XML Conf 2006 First Day, Second Day et Third Day (Keith Fahlgren)
  6. XML 2006 - Day One, Google Checkout API, You WILL Store XML, Day Two, JSON, The Fat-Free Alternative to XML, What powers Web 2.0 Mashups, Panel: Web 2.0 and XML, Using XML for Web Site Design, Development, and Maintenance, (Robin Hastings)
  7. XML 2006 Keynote, If I had a hammer..., Transitioning from SGML to XML at Cessna, Project Management panel, The ODF Plugin for MS Office, ODF plug-in, continued..., Word and OpenOffice for XML authoring, Panel, continued, Panel, part III, XML for Magazines, XML, InCopy, and InDesign, Scribus non grata, Day Two Keynote, External vs. internal DTDs, Vendor PechaKucha, XML in Legislation, Content Management APIs, Case study on single-sourcing by a publisher and Not the takeaway I was expecting (Sarah O'Keefe)
  8. XML 2006 Opening Keynote, XQueryP: An XML Application Development Language, PHP and XML: Reusing Other People's Information On Your Website, Language Support for Web Service Development, Panel: Word and OpenOffice for XML Authoring, Fun and Profit with the Google Checkout API, Panel: XML Pipeline Processing, Unleashing the power of XML, Case Study: Managing XML for a Global Content Delivery Platform, Web Publishing 2.0, What Powers Web2.0 Mashups, Panel: Web 2.0 and XML, An XQuery Servlet for RESTful Data Services and Meta-stylesheets (Dan Speck)
  9. XML 2006 Synopsis: Are we there yet? (Chimezie Ogbuji)

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