Peux-tu donner des exemples concrets de ce que tu avances stp? parce que là, ça s'apparente plutôt à du FUD pur et simple, quelque soit la position prise d'ailleurs.
Prends simplement le RTF (qui est complètement spécifié et mis-à-jour), j'ai tenté de l'implémenter: et ben c'est la merde, pq? ils ont pris word, regarder comment il faisait leur bidouille et mapper leur truc dessus. Soyons plus précis les tables par exemples: elles sont mappés sur la gestion des tables de Word, t'as pas le choix, si ton application ne les gères pas de la même façon (c'tait mon cas), tu dois te taper la conversion. Voilà donc un format ouvert qui n'a pas été conçus pour cela, je ne doute pas que ça facilite la vie de word, et qu'il le parse mieux que quiconque...
Pour les formats ouvert parfois désastreux à l'implémentation, regarde simplement tout les standard existant pas encore vraiment implémenter complètement (rien que du côté w3c y'en a déjà pas mal;-). Mais reprenons notre exemple des tables: le format d'une table HTML est simple, clair, relativement non ambigu... mais il souffre d'un défaut: il faut avoir toutes la table pour pouvoir commencer à la rendre (on peut bidouiller en commencant plus tôt, mais pas dans tous les cas... et ça rajoute des couches...), donc en pratique: le format est théoriquement beau, mais s'il forcait la spécification des tailles de colonnes, l'implémentation du parser serait à la fois plus simple et efficace... dans le cas de l'HTML nos machines sont assez puissantes, et les tables, en principe suffisemment petites pour que ça ne pose pas de problème, mais ça montre je trouve correctement le tradeoff "ouverture *réelle*"/"facilité rapidité de l'implémentation". Je pense que dans la pratique, ça doit être un mix: il doit exister des formats ouvert (et conçus dans un but d'ouverture) pour la publications de document (HTML, PDF, ...) et les formats qui vont bien avec les applications histoire d'avoir des applications plus performantes.
Ceci dit, je ne dis pas que propriétaire est mieux, je dis simplement qu'il faut pas se leurrer "ouvert" ne veut pas dire que c'est toujours exploitable... tout comme open source ou libre ne veut pas forcément dire logiciel de qualité... Je tenais juste à souligner le fait que le problème des formats est plus complexe qu'avoir les spec, il faut encore savoir en faire quelques choses. La prochaine version d'Office pond des fichiers XML (en ayant regardé rapidement ça a l'air assez "correct", avec schema et ce qu'il faut, j'ai pas fouillé la question cependant), tu crois réellement que ça va permettre à la concurrence de lire parfaitement leur fichier? (la réponse est non pour ceux ayant déjà vu du XML office).
[^] # Re: Encore un argument de poids pour les formats ouverts
Posté par tene . En réponse à la dépêche Encore un argument de poids pour les formats ouverts. Évalué à 1.
Prends simplement le RTF (qui est complètement spécifié et mis-à-jour), j'ai tenté de l'implémenter: et ben c'est la merde, pq? ils ont pris word, regarder comment il faisait leur bidouille et mapper leur truc dessus. Soyons plus précis les tables par exemples: elles sont mappés sur la gestion des tables de Word, t'as pas le choix, si ton application ne les gères pas de la même façon (c'tait mon cas), tu dois te taper la conversion. Voilà donc un format ouvert qui n'a pas été conçus pour cela, je ne doute pas que ça facilite la vie de word, et qu'il le parse mieux que quiconque...
Pour les formats ouvert parfois désastreux à l'implémentation, regarde simplement tout les standard existant pas encore vraiment implémenter complètement (rien que du côté w3c y'en a déjà pas mal;-). Mais reprenons notre exemple des tables: le format d'une table HTML est simple, clair, relativement non ambigu... mais il souffre d'un défaut: il faut avoir toutes la table pour pouvoir commencer à la rendre (on peut bidouiller en commencant plus tôt, mais pas dans tous les cas... et ça rajoute des couches...), donc en pratique: le format est théoriquement beau, mais s'il forcait la spécification des tailles de colonnes, l'implémentation du parser serait à la fois plus simple et efficace... dans le cas de l'HTML nos machines sont assez puissantes, et les tables, en principe suffisemment petites pour que ça ne pose pas de problème, mais ça montre je trouve correctement le tradeoff "ouverture *réelle*"/"facilité rapidité de l'implémentation". Je pense que dans la pratique, ça doit être un mix: il doit exister des formats ouvert (et conçus dans un but d'ouverture) pour la publications de document (HTML, PDF, ...) et les formats qui vont bien avec les applications histoire d'avoir des applications plus performantes.
Ceci dit, je ne dis pas que propriétaire est mieux, je dis simplement qu'il faut pas se leurrer "ouvert" ne veut pas dire que c'est toujours exploitable... tout comme open source ou libre ne veut pas forcément dire logiciel de qualité... Je tenais juste à souligner le fait que le problème des formats est plus complexe qu'avoir les spec, il faut encore savoir en faire quelques choses. La prochaine version d'Office pond des fichiers XML (en ayant regardé rapidement ça a l'air assez "correct", avec schema et ce qu'il faut, j'ai pas fouillé la question cependant), tu crois réellement que ça va permettre à la concurrence de lire parfaitement leur fichier? (la réponse est non pour ceux ayant déjà vu du XML office).