E0, le retour du fils de la vengeance

Je suis content de voir qu’on parle toujours d’un éven­tuel reboot de cette montagne de spéci­fi­ca­tions EPUB. C’est à la fois super complexe et pas mal contraint. Plus on avance plus on ajoute des options et des spécia­li­sa­tions pour des usages, et plus on s’en­fonce dans des matrices de compa­ti­bi­lité entre les conte­nus et les lecteurs.

Ça ne peut qu’ex­plo­ser et je n’ai pas vu en quoi cette surs­pé­ci­fi­ca­tion de comment coder les conte­nus appor­tait une valeur signi­fi­ca­tive 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 commen­taires à chaud sur la seconde partie. Mis à part le dernier, c’est essen­tiel­le­ment reti­rer des contraintes ou simpli­fier.

(2.2, 4) J’au­rais 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’avan­cer ou recu­ler séquen­tiel­le­ment. Si un spine peut être utile, il n’est en rien indis­pen­sable et pour­rait être recréé par une analyse rapide si vrai­ment néces­saire.

(2.3) Je rendrais option­nelle la TOC. Là aussi, elle me parait perti­nente et utile dans la plupart des usages mais je ne vois pas pourquoi elle serait indis­pen­sable au bon fonc­tion­ne­ment de la lecture ou du moteur de lecture. Si elle est absen­te… et bien il n’y en a pas.

(2._) À l’in­verse, j’au­rais bien aimé un moyen d’ex­ter­na­li­ser les diffé­rentes <nav> propo­sées, ainsi que le bloc de méta­don­né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’em­barquer direc­te­ment dans le contenu du fichier de navi­ga­tion.

Je vois d’ailleurs un vrai bonus sur le fait d’uti­li­ser un <link rel> déjà exis­tant. Je n’ai pas l’im­pres­sion que ça coûte­rait cher à un éven­tuel moteur de lecture que de le permettre, mais ça libè­re­rait les auteurs sur comment ils veulent présen­ter les conte­nus.

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

(2.1) Je rendrais même option­nel le bloc de méta­don­nées et le <header> asso­cié en le rendant juste recom­mandé. La seule méta­don­née essen­tielle étant le titre, déjà présent dans la balise <title>. Tout requis supplé­men­taire est un frein à la publi­ca­tion dont je ne vois pas le béné­fice.

Enten­dons-nous bien, j’ai envie de mili­ter pour des blocs de méta­don­nées ultra-complets, plus que les EPUB actuels. Je ne vois cepen­dant simple­ment pas de béné­fice à refu­ser une publi­ca­tion à laquelle il n’y a pas d’au­teur indiqué, ou à laquelle il manque une autre méta­don­née que le titre.

(2.1) Toujours pour le bloc de méta­don­nées, je ne comprends pas pourquoi impo­ser l’at­tri­but vocab. J’ai l’im­pres­sion d’une recom­man­da­tion 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’au­tant moins qu’à l’in­verse l’exemple utilise du Dublin Core sans expli­ci­ter l’adresse du préfixe dc. Je n’ai rien contre les conven­tions simples, mais dans ce cas allons-y jusqu’au bout.

(_._) Plus géné­ra­le­ment je suis dubi­ta­tif sur l’in­té­rêt d’im­po­ser quoi que ce soit d’autre que le nom du fichier de navi­ga­tion qui empê­che­rait de simple­ment zipper un fichier html ou une collec­tion de fichiers html déjà exis­tants.

(2.1) Je suis dubi­ta­tif sur la préco­ni­sa­tion de RDFa pour les méta­don­nées. Je suis person­nel­le­ment revenu des formats qui mélangent données et méta­don­nées. C’est une contrainte pour l’au­teur alors que la valeur ajou­tée reste à démon­trer. RDFa lui-même n’est pas la syntaxe qui a le mieux pris sur le web pour l’ins­tant. Pour ces deux raisons, propo­ser JSON-LD m’au­rait semblé plus perti­nent.

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

(2._) Je suis dubi­ta­tif sur l’uti­li­sa­tion des attri­buts id pour diffé­ren­cier les diffé­rentes sections de navi­ga­tion. L’at­tri­but 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 docu­ment. La complexité étant déjà présente, autant l’uti­li­ser. À défaut, j’au­rais même préféré un attri­but data-.

(2.1) Je suis gêné par l’obli­ga­tion d’avoir une balise <title> et une méta­don­née dc:title iden­tiques. Je n’aime pas les doublons et donc un seul des deux devrait être reconnu comme norma­tif (et malheu­reu­se­ment l’obli­ga­tion pour les méta­don­nées d’être dans un <header> m’em­pê­chera d’uti­li­ser le dc:title direc­te­ment sur le <title>).

C’est d’au­tant plus vrai qu’il peut y avoir des diffé­rence entre le titre présenté à l’uti­li­sa­teur et celui dans les méta­don­nées. Le cas d’usage le plus clas­sique que j’ai vu est la gestion des tomes et des séries. Dans les méta­don­nées je code ce qu’est le titre de la publi­ca­tion et sa série, son tome, sa collec­tion, etc. À l’uti­li­sa­teur, partout où doit appa­raitre le titre, je vais par contre éviter de me repo­ser sur le logi­ciel de lecture pour savoir s’il doit ou non préfixer/complé­ter par la série ou par la collec­tion. Je vais manuel­le­ment mettre un titre utili­sa­teur « 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 telle­ment fréquent et pose telle­ment de problèmes dans les bases de données biblio­gra­phiques exis­tantes que ça serait dommage de s’en passer.

(1.0) Je ne vois pas l’in­té­rêt d’im­po­ser l’ex­ten­sion e0. Indiquer l’ex­ten­sion cano­nique est une bonne chose mais l’im­po­ser risque d’ame­ner des lecteurs qui n’ac­cep­te­ront que celle-ci, alors que la spéci­fi­ca­tion e0 telle quelle pour­rait permettre de lire une quan­tité impres­sion­nante d’ar­chives zip déjà exis­tantes qui commencent par un index.html.

(_._) Même si on ne se limite pas aux livres, le cas d’usage étant telle­ment courant, j’au­rais aimé qu’on recom­mande une manière de faire réfé­rence à une image de couver­ture, proba­ble­ment avec un <meta> ou un <link> vu que le codage offi­ciel EPUB3 ne sera pas valable ici.