> > Le 7 janvier 2014 14:43, Eric <eric...@sfr.fr> a écrit : > Il faudrait dans ce cas utiliser directement le format binaire sans passer > par le XML. >
C'est une vieille rengaine qu'on reproche à XML alors que ce format a été fait d'abord pour permettre des échanges de données interopérables sur lequel on peut mapper un schéma de données. Et de toute façon pas besoi nde format binaire si on veut garder ces fonctionalités : une compression standard (zip/deflate, gzip) suffit à éviter d'avoir à maintenir un nouveau parseur. Ceux qui n'aiment pas parser su XML et sacrifie la possibilité de mapper simplement un schéma (car le schéma est présupposé) peuvent toujours passer à JSON, de plus en plus populaire, mais qui pose des problèmes d'évolutivité et de compatiilité des schémas de données. Ceci dit, le schéma des données XML d'OSM est relativement figé depuis assez longtemps (même si de nouvelles primitives géométriques sont ajoutées en plus des noeuds, chemins et relations, cela ne changera pas fondamentalement la structure qui est ultra simple. Une API OSM fournissant du JSON directement serait utile (et question compression HTTP prend en charge ça durant le transport sans avoir à écrire un nouveau parseur là aussi. Si on veut plus compact, ce n'est plus le schéma OSM de base mais celui des "features OpenGIS" qui est à développer davantage (et aussi certainement à proposer en version JSON et pas seulement XML). Franchement pas besoin de développer un format binaire (même les documents de traitement de texte ou feuilles de calcul sont maintenant en format XML compressé et ça marche très bien et même mieux que de maintenir les anciens formats binaires, trop souvent propriétaires et très mal documentés, avec une interopérabilité faible). Les seuls formats binaires relativement bien supportés sont ceux soutenus par une norme internationale comme les conteneurs de streams MPEG (pour empaqueter audio, vidéo, sous-titres, métadonnées, avec des points de synchronisation entre les flux et une optimisation sur la taille optimale de chaque fragment pour permettre des accès aléatoires sans avoir à parser tout le contenu depuis le début). Les formats binaires ont aussi des problèmes de compatibilité connus, notamment sur l'ordonnancement des octets, le placement des bits dans les octets pour les champs de bits, et la précision des nombres (sans oublier aussi les formats de nombre en virgule flottante, même avec la norme IEEE associée, que tous les processeurs ne savent pas interpréter et qu'il est compliqué et très lent de parser bit par bit pour obtenir une valeur utilisable). Que ceu xqui n'aiment pas XML (trop compliqué à parser alors qu'il y a des parseurs natifs efficaces sur toutes les plateformes aujourd'hui), peuvent passer à JSON. Mais gardons les schémas de données smples, et avec le moins de contraintes possibles pour faciliter les réutilisations: la structure des fichiers interopérables doit être la plus simple possible, avec peu de "profondeur" d'imbrication des éléments. Ensuite chaque aplication pourra utiliser ses propres schémas internes pour un traitement plus efficace, si elle en a besoin. Personnellement je n'aime pas les formats binaires pour les échanges de données, ils sont plus une gêne qu'ils ne sont utiles.
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
