E0, le retour du fils de la vengeance

Je suis content de voir qu’on parle toujours d’un éventuel reboot de cette montagne de spécifications EPUB. C’est à la fois super complexe et pas mal contraint. Plus on avance plus on ajoute des options et des spécialisations pour des usages, et plus on s’enfonce dans des matrices de compatibilité entre les contenus et les lecteurs.

Ça ne peut qu’exploser et je n’ai pas vu en quoi cette surspécification de comment coder les contenus apportait une valeur significative par rapport à ce qu’on fait déjà sur le web.

Bref, Daniel remet ça sur la table, et je le trouve modéré sur les problèmes d’EPUB. Je suis certain qu’il aurait pu mettre des listes 3 ou 4 fois plus longues s’il en avait envie.


Quelques commentaires à chaud sur la seconde partie. Mis à part le dernier, c’est essentiellement retirer des contraintes ou simplifier.

(2.2, 4) J’aurais retiré le spine, qui fait doublon avec les rel=prev/next. Dans les cas d’usage que je vois, le moteur de lecture a surtout besoin d’avancer ou reculer séquentiellement. Si un spine peut être utile, il n’est en rien indispensable et pourrait être recréé par une analyse rapide si vraiment nécessaire.

(2.3) Je rendrais optionnelle la TOC. Là aussi, elle me parait pertinente et utile dans la plupart des usages mais je ne vois pas pourquoi elle serait indispensable au bon fonctionnement de la lecture ou du moteur de lecture. Si elle est absente… et bien il n’y en a pas.

(2._) À l’inverse, j’aurais bien aimé un moyen d’externaliser les différentes <nav> proposées, ainsi que le bloc de métadonnées. L’idée c’est de pouvoir faire référence à un fichier séparé via un <link rel=toc href=toc.html> plutôt que l’embarquer directement dans le contenu du fichier de navigation.

Je vois d’ailleurs un vrai bonus sur le fait d’utiliser un <link rel> déjà existant. Je n’ai pas l’impression que ça coûterait cher à un éventuel moteur de lecture que de le permettre, mais ça libèrerait les auteurs sur comment ils veulent présenter les contenus.

Tel quel si je veux montrer la TOC à la fin du document et pas en début de lecture, il faudrait sinon que je la cache en CSS dans le document de navigation puis que la doublonne dans un fichier de contenu tiers.

(2.1) Je rendrais même optionnel le bloc de métadonnées et le <header> associé en le rendant juste recommandé. La seule métadonnée essentielle étant le titre, déjà présent dans la balise <title>. Tout requis supplémentaire est un frein à la publication dont je ne vois pas le bénéfice.

Entendons-nous bien, j’ai envie de militer pour des blocs de métadonnées ultra-complets, plus que les EPUB actuels. Je ne vois cependant simplement pas de bénéfice à refuser une publication à laquelle il n’y a pas d’auteur indiqué, ou à laquelle il manque une autre métadonnée que le titre.

(2.1) Toujours pour le bloc de métadonnées, je ne comprends pas pourquoi imposer l’attribut vocab. J’ai l’impression d’une recommandation de forme inutile pour ce http://www.idpf.org/2007/opf. On le mettra si on en a besoin pour du RDFa, et sinon on s’en passera très bien.

Je comprends d’autant moins qu’à l’inverse l’exemple utilise du Dublin Core sans expliciter l’adresse du préfixe dc. Je n’ai rien contre les conventions simples, mais dans ce cas allons-y jusqu’au bout.

(_._) Plus généralement je suis dubitatif sur l’intérêt d’imposer quoi que ce soit d’autre que le nom du fichier de navigation qui empêcherait de simplement zipper un fichier html ou une collection de fichiers html déjà existants.

(2.1) Je suis dubitatif sur la préconisation de RDFa pour les métadonnées. Je suis personnellement revenu des formats qui mélangent données et métadonnées. C’est une contrainte pour l’auteur alors que la valeur ajoutée reste à démontrer. RDFa lui-même n’est pas la syntaxe qui a le mieux pris sur le web pour l’instant. Pour ces deux raisons, proposer JSON-LD m’aurait semblé plus pertinent.

J’avoue cependant qu’on peut faire des guerres de clocher pendant des années sur ces questions et RDFa ne me semble pas un mauvais choix non plus.

(2._) Je suis dubitatif sur l’utilisation des attributs id pour différencier les différentes sections de navigation. L’attribut role me semble plus adapté quand c’est possible. L’exemple en 2.6 montre d’ailleurs un role=doc-toc.

C’est encore plus vrai si de toutes façons on impose RDFa dans le document. La complexité étant déjà présente, autant l’utiliser. À défaut, j’aurais même préféré un attribut data-.

(2.1) Je suis gêné par l’obligation d’avoir une balise <title> et une métadonnée dc:title identiques. Je n’aime pas les doublons et donc un seul des deux devrait être reconnu comme normatif (et malheureusement l’obligation pour les métadonnées d’être dans un <header> m’empêchera d’utiliser le dc:title directement sur le <title>).

C’est d’autant plus vrai qu’il peut y avoir des différence entre le titre présenté à l’utilisateur et celui dans les métadonnées. Le cas d’usage le plus classique que j’ai vu est la gestion des tomes et des séries. Dans les métadonnées je code ce qu’est le titre de la publication et sa série, son tome, sa collection, etc. À l’utilisateur, partout où doit apparaitre le titre, je vais par contre éviter de me reposer sur le logiciel de lecture pour savoir s’il doit ou non préfixer/compléter par la série ou par la collection. Je vais manuellement mettre un titre utilisateur « Ma série : Mon titre » ou « Mon titre – Ma série ».

Je sais qu’on ne se contente pas que des livres mais le cas d’usage est tellement fréquent et pose tellement de problèmes dans les bases de données bibliographiques existantes que ça serait dommage de s’en passer.

(1.0) Je ne vois pas l’intérêt d’imposer l’extension e0. Indiquer l’extension canonique est une bonne chose mais l’imposer risque d’amener des lecteurs qui n’accepteront que celle-ci, alors que la spécification e0 telle quelle pourrait permettre de lire une quantité impressionnante d’archives zip déjà existantes qui commencent par un index.html.

(_._) Même si on ne se limite pas aux livres, le cas d’usage étant tellement courant, j’aurais aimé qu’on recommande une manière de faire référence à une image de couverture, probablement avec un <meta> ou un <link> vu que le codage officiel EPUB3 ne sera pas valable ici.