Et puis l'API devrait abandonner le format XML (trop verbeux et trop permissif), et passer au JSON (avec un schéma documenté pour les clés de base)...
Ou une alternative comme Turtle (plus destiné à la lisibilité et le travail par un lecteur humain, moyennant des conventions sur l'indentation en faisant attention aux différences entre tabulations et espaces que certains éditeurs de texte insèrent automatiquement ou remplacent dans un sens ou l'autre et pas forcément avec les mêmes règles de conversion du tabulateur: proscrire les tabulations, ou les imposer partout, une difficulté qui existe aussi dans d'autres langages de programmation comme Python... mais les utilisateurs du format Turtle le feront pour des éditions en masse et devraient avoir des outils de travail adaptés) Un autre format équivalent est le format INI (mais il y a nécessité de créer des groupes pour factoriser les clés parentes (et utiliser alors un séparateur conventionnel entre les clés préfixes ou les clés des paires "clé1:clé2"=valeur", qui peut être le ":", un "/" ou un "\") : l'avantage est qu'il est accessible aux débutants sans trop de contraintes sur les éditeurs (moyennant une certaine redondance sur les clés parentes) Pas besoin du XML (ou encore moins du SGML encore plus dificile à traiter correctement), qui différencie attributs et contenus d'un élément, une distinction à mon avis inutile, les contenus de balise n'étant que la valeur d'une clé particulière (anonyme) dans un objet parent. Le XML n'a d'intérêt que si on peut mélanger des schémas d'espaces de nom dans un même document, et jouer avec les différentes options (comme "xml:whitespace") et différentes formes pour l'échappement de caractères ou les entités nommées et il est trop complexe/couteux à parser: sa verbosité est directement liés à sa trop grande flexibilité. D'ailleurs XML est en perte de vitesse face à JSON bien plus efficace (et permettant pourtant la gestion de schémas si on en a besoin, en incluant les indicateurs de schémas au sein des données dans un objet conteneur). J'aime beaucoup JSON, mais sa version standard a aussi des contraintes un peu gênantes, notamment les guillemets ou quotes obligatoires et qu'on pourrait relâcher sur un format à peine plus flexible (tant que les clés ou valeurs se limitent à des nombres ou des chaines sans virgule ni crochets ou accolades et tant que les blancs sont "trimmables" et compressibles: JSON permet l'indentation comme on veut ou automatique, on peut se passer des guillemets ou quotes; si on veut des quotes ou guillemets dans les valeurs, il leur faut un échappement simple; et on n'en a besoin que dans les valeurs, pas dans les clés). D'autres formats sont aussi envisageables, dont les listes de triplets RDF (là encore il faut quelques règles de conversion pour assurer la bijection des déclarations valides, mais ce n'est pas insurmontable): mais le RDF est un excellent format "natif" plutôt destiné aux bases de données dans un traitement automatique (car on y trouve pléthores de références uniques sous forme de GUID, qu'un éditeur humain "lambda" aura beaucoup de mal à lire, même si c'est certainement aujourd'hui le système le plus flexible aux données structurées complexes). Le RDF dispose d'un langage de requêtes standardisé par le W3C et fonctionne très bien avec les bases de donénes de type "hash store" (dont Wikibase sur lequel se base Wikidata, qui pourtant a un schéma de conversion en JSON, en plus de l'interface web de présentation et contenant les outils de modifications sous forme de javascript pour utiliser l'API de façon assistée). L'API (sur le serveur) pourrait supporter différents formats (pas que le XML), comme le font déjà des "API flexibles" telles celles pour Mediawiki ou Overpass (que presque plus personne n'utilise en syntaxe XML pour les requêtes et réponses, XML étant encore là juste pour la compatibilité ascendante avec les outils existants qui ne s'attendent pas à autre chose)... Le jeu. 7 mai 2020 à 10:32, Yves P. <[email protected]> a écrit : > > Cela ne dit pas comment les clés _1, _2 seront assemblées en une seule: > en séparant les valeurs par des point-virgules, des virgules, des espaces > ou rien du tout (concaténation simple). > Pour moi c'était évident : concaténation simple :) > > > > > L'usage actuel serait que des valeurs multiples sont dans des _1, _2, > etc. séparés et que leur séparation par défaut serait alors le > point-virgule (ce que fait déjà iD et certains éditeurs pour des valeurs > multiples ou différentes après une fusion de deux objets: ces _2 sont > plutôt l'indication d'une erreur ou ambiguïté à traiter manuellement, > l'éditeur ayant été incapable de choisir entre des valeurs potentiellement > incompatibles)… > Je dois avoué que je n'ai pas regardé depuis un moment ce que produit iD :| > > > Mais alors cela ne résoud toujours pas le problème des valeurs longues > où ce point-virgule "'implicite" sera faux (par exemple les balises > "opening_hours" qui ont des règles spécifiques de séparation). > Les DataItems peuvent (déjà ?) indiquer si le tag accepte des valeurs > multiples. > Si oui, la concaténation se fait avec un point virgule, sinon c'est une > concaténation simple. > > Pour le cas de "opening_hours", ça ne fonctionne pas actuellement de toute > façon. > > > Si OSM doit évoluer, c'est pour permettre des valeurs de balises > "structurées". > Andy Allan parle d'évolution de l'API en "douceur" ;) > Ceci n'est donc pas probable pour la v0.7, peut-être la v2.0 ? > > __ > Yves > _______________________________________________ > Talk-fr mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/talk-fr >
_______________________________________________ Talk-fr mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-fr
