Mon blog

Les blogs et la syndication étant actuellement deux des occupations les plus populaires sur le Web, il fallait donc un livre chez O'Reilly sur les formats de syndication : c'est chose faite.

Ce livre couvre les différents formats RSS et une version assez préliminaire du format Atom (qui vient d'être normalisé dans le RFC 4287). Le chapitre historique qui retrace l'histoire de la syndication et des guerres entre formats nommés RSS est d'ailleurs passionnant et éclaire bien des questions.

Il continue par un chapitre sur l'utilisation de la syndication (il cite de nombreux outils mais pas un de mes favoris, rss2email, qui permet de convertir un flux de syndication en liste de diffusion par courrier). Puis il décrit en détail les principaux formats de syndication, s'attardant sur les innombrables modules qui ont fait le succès de la version 1.0 de RSS (celle qui utilise RDF).

Les chapitres suivants sont plus techniques : analyse de flux de syndication depuis un programme (presque tous les exemples sont en Perl), avec discussion pour savoir si l'analyseur doit être strict ou bien laxiste, des considérations sur les flux réels rencontrés dans la nature et surtout un chapitre passionnant sur des utilisations « inhabituelles » de la syndication, essentiellement pour des tâches d'administration système ou bien pour exploiter des sources d'information qui ne sont pas syndicatées (par exemple Google, avec un programme de conversion de recherches Google en flux RSS).

Bref, un livre assez court, très bien fait, peu à jour pour tout ce qui concerne Atom mais qui est quand même une bonne introduction au monde merveilleux de la syndication.

Il existe désormais trois langages courants pour écrire des schémas XML c'est-à-dire pour décrire les éléments autorisés ou interdits dans un document XML. RelaxNG, le plus récent, est le moins connu des trois et méritait donc bien un livre chez O'Reilly, avec un faisan sur la couverture, pour gagner davantage de popularité.

Autrefois, les schémas XML ne pouvaient s'écrire qu'avec une DTD et c'est la seule solution décrite dans la norme XML. Les limitations des DTD ont mené à l'invention de nouveaux langages, le plus connu étant W3C Schema, aussi dit XSD.

XSD est très complexe, souffre d'une syntaxe XML verbeuse, et est en même temps limité dans les schémas qu'il permet de décrire. Bien qu'il bénéficie d'une présence supérieure dans les médias, il n'a pas été choisi pour certains gros projets (Docbook, OpenDocument, Atom, etc) qui ont préféré RelaxNG.

C'est un signe de la simplicité de RelaxNG que le fait que ce livre soit à la fois relativement mince et très complet : il est rare qu'un sujet en soit absent. L'annotation d'un schéma (par exemple pour le documenter ou pour y mettre des métadonnées) fait ainsi l'objet d'un chapitre entier.

L'auteur, Eric van der Vlist, est également l'auteur du O'Reilly sur XSD, il connait donc bien les deux "concurrents", même si sa préférence pour RelaxNG ne fait guère de doute. Francophone, il est également un des piliers de la liste xml-fr, où il répond en général très rapidement aux questions.

Ce livre couvre donc l'essentiel de RelaxNG : ses principes (ne valider que la structure, pas le contenu des éléments, ne pas changer les valeurs des éléments), puis sa syntaxe (RelaxNG a deux syntaxes, une XML et une dite compacte, bien plus lisible).

Il explique ensuite comment contraindre les valeurs des éléments grâce aux bibliothèques de types (extérieures à RelaxNG proprement dit), puis explique en détail comment réaliser des schémas qui, au lieu d'être des blocs monolithiques, soient extensibles ou restrictibles facilement, de façon à ce que leurs utilisateurs puissent n'utiliser que ce qu'ils veulent.

Le livre se termine sur un remarquable chapitre sur le déterminisme dans les schémas et pourquoi RelaxNG ne l'impose pas.

Notez que le schéma des fichiers XML de ce blog est écrit en RelaxNG.

Aujourd'hui, on entend et on lit très souvent, comme si cela allait de soi, que l'interface d'un logiciel doit être graphique et, de préférence, WYSIWYG. Toute mise en doute de ce dogme ne peut être, semble t-il, que l'œuvre de dinosaures obtus, attachés aux incompréhensibles commandes d'Unix. C'est ce dogme que Neal Stephenson, le célèbre auteur de la trilogie "Cryptonomicon" a décidé d'ébranler.

Dans ce petit livre, le raisonnement de Stephenson est simple : la ligne de commande, contrairement à l'interface graphique, est un langage. Comme tout langage, elle prend du temps à être maitrisée. Mais, une fois que c'est fait, elle permet bien plus d'expressivité qu'une interface graphique, qui ne permet que de choisir parmi des options pré-définies.

Stephenson compare l'utilisateur de l'interface graphique à un singe qui ne sait pas parler, seulement montrer du doigt (ou de la souris) la banane qu'il veut, peut-être en ajoutant quelques grognements.

Stephenson ne se limite pas au sujet évoqué dans le titre : il analyse toute l'évolution de l'informatique depuis vingt ans, l'influence des feuilletons télé et de Disneyland sur la mentalité états-unienne, les voitures, et les épopées antiques comme Gilgamesh. Qui a dit que les informaticiens étaient incultes et ne philosophaient pas ?

Un livre original qui est plutôt orienté vers l'apprentissage de la programmation fonctionnelle que vers celui du langage Haskell.

Il n'est probablement pas indispensable de savoir déjà programmer et ce livre pourrait être utilisé comme support de cours. L'auteur commence par les concepts de base de la programmation fonctionnelle, et, pour une fois, les exemples ne sont pas tous les sempiternels exemples mathématiques à base de factorielle et de Fibonacci mais des exemples graphiques avec des images que l'on transforme (pour faciliter la mise en œuvre, une intéressante implémentation entièrement en art ASCII est présentée par la suite).

Il explique ensuite l'environnement Hugs, utilisé pour la pratique, puis expose les différents concepts utilisés : listes, fonctions comme objets de première classe (pouvant être passées en argument), application partielle et curryfication, introduction à la preuve de programmes, le système des classes, la programmation paresseuse...

Comme le livre vise à enseigner la programmation fonctionnelle, plus que le langage Haskell, d'importants pans de celui-ci ne sont pas traités du tout : les monades sont très vite expédiées, les enregistrements nommés pas mentionnés, l'inférence de types est complètement absente (et l'auteur déclare donc systématiquement ses types). Les questions pratiques comme le contenu du Prélude, les bibliothèques existantes ou les entrées/sorties sont très peu traitées. Le lecteur ne doit donc pas s'imaginer qu'il pourra programmer en Haskell immédiatement, ni lire le code de darcs immédiatement.

Au jour d'aujourd'hui, ce livre représente un état de l'art du Web débarassé des scories de la "guerre des browsers", déclenchée par Netscape et qui avait abouti à un grande balkanisation du Web.

Un des effets de cette guerre avait été la prolifération d'éléments HTML non-standards, produisant des effets visuels supposés attirer les clients vers un navigateur particulier, comme le célèbre <BLINK>.

En même temps que cette guerre, et s'appuyant sur cette course aux effets visuels, le webmestre moyen, en général peu cultivé en informatique documentaire, avait pris l'habitude de ne plus séparer contenu et présentation (ce qui était pourtant un principe cardinal du Web) et de tout mélanger, structure et effets visuels. La version 3.2 de HTML était allé particulièrement loin en ce sens.

Aujourd'hui, on en est revenu, on comprend mieux l'intérêt de séparer le fond (utile par exemple aux moteurs de recherche) de la forme. Et les normes ont évolué, la version 2 de CSS ajoutant à CSS ce qui lui manquait : la possibilité de positionner des éléments sur la page. Même les sites très pro-CSS devaient utiliser des tables HTML dès qu'il fallait positionner, par exemple un menu à droite. Avec CSS 2, on peut enfin écrire une page HTML sans une seule indication de présentation, celle-ci étant concentrée dans la feuille de style CSS.

Il ne reste donc plus qu'à apprendre CSS 2. Si CSS 1 était assez simple, la version 2 oblige les webmestres à apprendre un peu d'informatique graphique et un livre n'est donc pas inutile. Celui-ci répond bien aux problèmes, il est très concret, ne couvre pas uniquement la norme mais aussi sa mise en œuvre dans les navigateurs, par exemple avec ses énormes bogues et limitations dans Microsoft Internet Explorer (CSS 2 est loin d'être correctement mis en œuvre partout).

Démarrant doucement, avec un exposé de CSS accessible aux débutants, le livre continue par un festival de trucs et de bricolages qui devraient satisfaire même les bons connaisseurs de CSS.

Le ton assez pontifiant du livre est souvent assez énervant, ainsi que la préciosité du langage mais les concepteurs de pages Web sont comme les informaticiens, ils manquent souvent de distance avec leur sujet.

[Avertissement : c'est le premier livre de la série "Pragmatic" que je lis. Cette série tente apparemment de faire l'intermédiaire entre O'Reilly et "XXX pour les nuls".]

Un bon livre pour deux sortes de public, ceux qui ne connaissent pas les systèmes de contrôle de versions (ou qui connaissent uniquement des systèmes très archaïques comme RCS ou ClearCase) et ceux qui font du CVS depuis dix ans et passent à Subversion.

Mise en page très agréable, bons dessins, la présentation vaut les O'Reilly.

Les explications sont correctes et détaillés. Une fois qu'on a accepté que tous les exemples soient avec des sources Java, tout se passe bien :-)

Le titre de pragmatic est assez mérité, il y a peu de discussions (par exemple les systèmes de contrôle de versions décentralisés sont à peine mentionnés), pour pouvoir passer aux tâches concrètes tout de suite.

Alors que j'utilisai déjà beaucoup Subversion, j'ai encore appris des commandes dans ce livre ("svn praise" qui affiche un fichier avec le nom du committeur de la ligne en face de chaque ligne) et des options ("svn status -u" qui vérifie le statut avec le serveur, pas uniquement en local).

Regret principal : dans une série qui se veut concrète, l'auteur n'a pas pensé à séparer clairement l'utilisation de Subversion de son administration (notamment dans les chapitres 7 et 8 sur l'organisation du dépôt). Or, il y a beaucoup plus d'utilisateurs que d'administrateurs et un livre où les chapitres Administration seraient regroupés en un endroit clairement marqué serait sans doute préférable pour les utilisateurs ordinaires.