Je connais cet article, qui est très intéressant effectivement, mais reste (et restera sûrement) entièrement théorique. Il m'est difficile de répondre sur l'étude (ou l'absence d'étude) concernant sa réalisation. Par contre les deux autres questions sont plus faciles.
Parce que ce serait trop compliqué de tout changer ?
En mars 2021, j'ai encore reçu un document rédigé avec le format Microsoft Word historique, introduit avec Word 97. En même temps que Clippy, en 1996. 25 ans d'inertie... Donc oui c'est très très très ... très très compliqué de tout changer.
Les suites bureautiques ont heureusement toutes un système de filtre pour importer des documents d'autres logiciels, mais encore aujourd'hui la lingua franca des documents éditables reste dans beaucoup d'esprits le format Microsoft Office 97-2003.
Les deux prétendants légitimes au trône sont les formats Microsoft Office Open XML et Open Document. Ce qui me transitionne pour ta deuxième question...
Parce qu'elle n'est pas appropriée (et pourquoi) ?
Tout d'abord, par rapport à l'article, il eut été intéressant que la comparaison ait également lieu avec le format OOXML et pas seulement ODT. L'OOXML répond notamment à la problématique mise en avant ici (comment modifier la diapo 42 sans tout réécrire) avec un découpage en fichiers distincts de chaque diapositive. (ce qui peut compliquer d'autres éléments dans l'implémentation, mais passons)
L'OOXML et l'ODT ont de nombreux points commun. Ils sont normalisés, sous la forme d'une archive zip embarquant des fichiers XML.
Pourquoi zip ? Parce qu'il est ouvert, libre de brevets, dans le domaine public depuis 1989, avec de multiples implémentations, et même normalisé ISO depuis 2015 (en conséquence de son usage dans l'ODT, l'OOXML et l'epub d'ailleurs). SQLite, a contrario, serait là dessus un mauvais choix : il n'existe à ma connaissance qu'une seule implémentation du format de fichier, et le format a largement évolué en 2004 avec l'introduction de SQLite3, avec une rupture de compatibilité.
Et en aparté, pourquoi XML ? Outre le fait que dans les années 2000 c'était le Format à la mode, avec un F majuscule, un point qu'on néglige énormément en ces temps de JSON, YAML et autres TOML, le XML a intégré de base une technologie fantastique : les namespaces. Cela permet d'avoir des dépendances à d'autres normes et donc d'éviter d'avoir à réinventer la roue.
L'en-tête du fichier content.xml d'un fichier ODT généré par LibreOffice Writer contient une quinzaine de namespaces. Plusieurs sont assez intéressants puisqu'ils aboutissent à une réduction de la taille de la norme OpenDocument : les formules mathématiques sont par exemple représentées en MathML, les modèles XForms peuvent être directement intégrés, on utilise RDF... Le point «And so forth» de l'article de SQLite est vite incompatible avec cette approche (découpage du contenu en tables, avec des relations entre les tables et cie), à moins de définir un schéma SQL extrêmement strict et précis, qui à lui seul représentera des milliers de lignes de SQL, et qui remplacerait du coup des morceaux de la norme ODT...
Si l'on s'arrête strictement au concept s/zip/SQLite/, le point qui moi me crispe d'emblée, c'est l'absence d'implémentation alternative du format SQLite 3 (j'ai bien trouvé en grattant 2/3 projets décédés...). Sans ça, on n'a pas de preuve de la qualité de la description du format de fichier.
Pour finir cette bien longue réponse, je pourrais également ajouter ces éléments de la norme OpenDocument :
- un fichier OpenDocument peut être représenté en un fichier XML unique, sans le .zip autour (§3.1.1 de la v1.2-part1)
- le «package» est défini dans la partie 3 de la norme, la partie la plus courte. Rien n'interdit de proposer à l'OASIS une évolution sur du SQLite3...
[^] # Re: Un (petit) peu HS : SQLite ?
Posté par Pinaraf . En réponse à la dépêche Hotspot, à la recherche du point chaud.... Évalué à 10.
Je connais cet article, qui est très intéressant effectivement, mais reste (et restera sûrement) entièrement théorique. Il m'est difficile de répondre sur l'étude (ou l'absence d'étude) concernant sa réalisation. Par contre les deux autres questions sont plus faciles.
En mars 2021, j'ai encore reçu un document rédigé avec le format Microsoft Word historique, introduit avec Word 97. En même temps que Clippy, en 1996. 25 ans d'inertie... Donc oui c'est très très très ... très très compliqué de tout changer.
Les suites bureautiques ont heureusement toutes un système de filtre pour importer des documents d'autres logiciels, mais encore aujourd'hui la lingua franca des documents éditables reste dans beaucoup d'esprits le format Microsoft Office 97-2003.
Les deux prétendants légitimes au trône sont les formats Microsoft Office Open XML et Open Document. Ce qui me transitionne pour ta deuxième question...
Tout d'abord, par rapport à l'article, il eut été intéressant que la comparaison ait également lieu avec le format OOXML et pas seulement ODT. L'OOXML répond notamment à la problématique mise en avant ici (comment modifier la diapo 42 sans tout réécrire) avec un découpage en fichiers distincts de chaque diapositive. (ce qui peut compliquer d'autres éléments dans l'implémentation, mais passons)
L'OOXML et l'ODT ont de nombreux points commun. Ils sont normalisés, sous la forme d'une archive zip embarquant des fichiers XML.
Pourquoi zip ? Parce qu'il est ouvert, libre de brevets, dans le domaine public depuis 1989, avec de multiples implémentations, et même normalisé ISO depuis 2015 (en conséquence de son usage dans l'ODT, l'OOXML et l'epub d'ailleurs). SQLite, a contrario, serait là dessus un mauvais choix : il n'existe à ma connaissance qu'une seule implémentation du format de fichier, et le format a largement évolué en 2004 avec l'introduction de SQLite3, avec une rupture de compatibilité.
Et en aparté, pourquoi XML ? Outre le fait que dans les années 2000 c'était le Format à la mode, avec un F majuscule, un point qu'on néglige énormément en ces temps de JSON, YAML et autres TOML, le XML a intégré de base une technologie fantastique : les namespaces. Cela permet d'avoir des dépendances à d'autres normes et donc d'éviter d'avoir à réinventer la roue.
L'en-tête du fichier content.xml d'un fichier ODT généré par LibreOffice Writer contient une quinzaine de namespaces. Plusieurs sont assez intéressants puisqu'ils aboutissent à une réduction de la taille de la norme OpenDocument : les formules mathématiques sont par exemple représentées en MathML, les modèles XForms peuvent être directement intégrés, on utilise RDF... Le point «And so forth» de l'article de SQLite est vite incompatible avec cette approche (découpage du contenu en tables, avec des relations entre les tables et cie), à moins de définir un schéma SQL extrêmement strict et précis, qui à lui seul représentera des milliers de lignes de SQL, et qui remplacerait du coup des morceaux de la norme ODT...
Si l'on s'arrête strictement au concept s/zip/SQLite/, le point qui moi me crispe d'emblée, c'est l'absence d'implémentation alternative du format SQLite 3 (j'ai bien trouvé en grattant 2/3 projets décédés...). Sans ça, on n'a pas de preuve de la qualité de la description du format de fichier.
Pour finir cette bien longue réponse, je pourrais également ajouter ces éléments de la norme OpenDocument :
- un fichier OpenDocument peut être représenté en un fichier XML unique, sans le .zip autour (§3.1.1 de la v1.2-part1)
- le «package» est défini dans la partie 3 de la norme, la partie la plus courte. Rien n'interdit de proposer à l'OASIS une évolution sur du SQLite3...