La nouvelle ne m’aurait pas effleurée si un Googler (membre du Conseil d’Adminsitration d’Ars Industrialis par ailleurs) ne m’en avait parlé. La nouvelle en question c’est la mise à disposition de Protocol Buffer par Google.

C’est quoi « Protocol Buffer » ? C’est le mécanisme qu’utilise en interne Google pour sérialiser des données structurées lors d’échanges entre des systèmes ou des applicatifs.

Mais aujourd’hui on fait çà en XML non ? Exact, mais la majorité des développeurs, surtout quand il s’agit ne s’agit pas de systèmes documentaires, n’ont jamais vraiment aimé XML.

Pourquoi ? « Trop verbeux » disent-ils.

C’est aussi l’avis des ingénieurs de Google qui ont mis au point ce mécanisme pour sérialiser les données qui s’échangent sous forme de message entre des applications de leur système d’information. Le principal avantage est le gain de temps, bien sûr ce gain de temps dans le traitement d’un message en « Protocol Buffer » est de l’ordre de la nano seconde, mais on sait que quand on a les infrastructures de Google, les nano-secondes ont tendance à se multiplier de manière exponentielle, d’où l’intérêt d’avoir des messages compilés, puisque c’est ce que propose Protocol Buffer.

Parlant d’optimisation, voici les chiffres qu’avance Google sur la base de l’exemple suivant en comparant Protocol Buffer et XML (ma traduction) :

Les Protocoles Buffers sont :

• plus simples
• de taille 3 à 10 fois plus petits
• 20 à 100 fois plus rapides
• moins ambigus
• génèrent des classes d’accès plus faciles à manipuler en programmation

Par exemple, si vous souhaitez modéliser une person avec un name et un email. En XML, aurez :

  <person>
    <name>John Doe</name>
    <email>jdoe@example.com</email>
  </person>

Alors que le message correspondant en protocol buffer (avec le protocole buffer au format texte) est :

# Textual representation of a protocol buffer.
# This is *not* the binary format used on the wire.
person {
  name: "John Doe"
  email: "jdoe@example.com"
}

Quand ce message est encodé au format binaire il aura une taille de 28 bytes et sera parsé en 100-200 nanosecondes. La version XML fait 69 bytes sans les espaces vides, et sera parsée en 5 000 à 10 0000 nanosecondes.

Bien sûr, ces chiffres ne deviennent significatifs que sur des architectures traitant des volumes importants et/ou nombreux, et où la rapidité de traitement est critique. Par ailleurs, Google précise bien que XML garde tout son sens dans un environnement documentaire avec des langages à balises comme pour l’HTML, et où il est important d’avoir du contenu self-descriptif puisque le sens d’un message en protocole buffer (l’équivalent de sa DTD) est à part, dans le fichier ayant l’extension .proto.

M’est d’avis que, là où il y a besoin de performance et qu’il y a de la donnée structurée, Protocol Buffer va vite décoller y compris dans l’environnement web sémantique qui lui aussi travaille sur des volumes importants et structurés. Inutile donc de craindre que Protocol Buffer fasse de l’ombre au web sémantique sous prétexte qu’il remplace le XML, puisque le web sémantique n’a rien à voir avec XML qui n’est qu’une sérialisation possible parmi d’autres.

Sur la page de présentation de Protocol Buffer vous trouverez tout ce qu’il faut : tutotrial, guides et APIs.

Related posts:

1. Introduction à XML Une introduction n’est pas, disait Heidegger, quelque chose de général...
2. Houston, we’ve got a problem Sacrées Logiques Descriptives, on n’a décidément pas fini d’en parler...
3. XML Pipeline Langage Un working draft de XML Pipeline Langage vient d’être publié....

Un working draft de XML Pipeline Langage vient d’être publié.

A rapprocher de ce que fait l’UIMA d’IBM ou le Document Processing de FAST, dont je parlais dans mon introduction au text-mining.

La démarche est intéressante pour normaliser les mashups et l’agrégation des contenus directement sur Web.

[Update] On lira avec plaisir et intérêt la note de Stéphane Bortzmeyer, toujours passionnant dans sa présentation des normes.

Related posts:

1. Le script pour tout le monde Yahoo propose à présent, via Yahoo Pipe, la possibilité de...
2. La plus courte definition du Web 2.0 Une application Web 2.0 est un formulaire de saisie en...
3. A propos de la virtualisation de Windows Nasstar (il faut aller voir leur site avec la video...

Une introduction n’est pas, disait Heidegger, quelque chose de général qui vous laisserait au pas de la porte d’une question. Non, une introduction se doit de vous introduire au coeur même du problème. C’est dans l’introduction que l’acte pédagogique se doit d’être le plus intense.

Quiconque s’est retrouvé devant un public pour enseigner quelque chose vous le dira : le commencement, l’introduction, va déterminer et conditionner toute la suite. Faisons un essai d’introduction à XML, en quelques lignes.

XML est une notation. Et au coeur même des premières pratiques de notation on trouve la liste.

• Faire la liste des courses
• C’est la rentrée, l’enseignant consulte la liste des noms pour faire l’appel.
• Les moteurs de recherche nous affichent des listes
• Les bibliothécaires constituent des listes de classement pour gérer leur catalogue.
• Le web c’est l’affichage des listes, et maintenant aussi le partage des listes
• Je commence un projet, quelle va être la liste des tâches ?
• La liste de mariage
• Fin de la liste

Au commencement est la liste. On ne fait rien sans une liste. Je pense même que toute pratique symbolique qui est portée par un dispositif technique, tel que l’écriture, commence par la constitution et l’utilisation de listes. Cela fait entrevoir la raison pour laquelle XML, en tant que norme de notation de listes, est si important dans le traitement des supports numérique.

Mais continuons : les techniques d’écriture de listes se sont diversifiées, particularisées et singularisées, en se donnant des ordres :

• Liste par ordre croissant ou décroissant

• Liste par ordre alphabétique

• Liste par ordre numérique

• Liste par ordre chronologique

On a même inventé des listes de listes, c’est à dire des listes imbriquées, celles sur lesquelles reposent précisément l’encodage XML.
Bien que l’écriture en XML dispose d’autres possibilités, le format de base d’un encodage XML reste la liste imbriquée, qui prend la forme d’une arborescence.

Représenter de l’information
On parle souvent de programmation XML, c’est un abus de langage: le programme accède et/ou produit des informations au format XML. Celui-ci n’est pas un langage de programmation, c’est un code pour représenter et décrire de l’information.

Un programme exécute la liste des instructions qui lui sont données.
Les programmes sont des listes d’exécution, alors que XML est une liste descriptive. L’informatique, c’est l’art d’articuler l’exécution de liste (algorithmes) avec la description des listes.

Programmer et encoder ne sont pas la même chose.
Vous pouvez être très bon en listes de description (XML) et être très mauvais en liste d’exécution (programmation).
Les compétences en liste de description XML sont moins courantes que les compétences en listes d’exécution, même si la tendance est en faveur des listes de description. Voilà pourquoi la bibliothéconomie et les sciences de l’information sont si importantes, ce que je préciserai dans une prochaine note.

Related posts:

1. De la temporalité des ontologies Cela fait un petit moment que je voulais ajouter des...
2. XML versus Protocol Buffer La nouvelle ne m’aurait pas effleurée si un Googler (membre...
3. XML Pipeline Langage Un working draft de XML Pipeline Langage vient d’être publié....