Note: je n'ai rien précisé concernant la façon de créer un échappement pour
les crochets, accolades, guillemets, apostrophes, et les pipe, virgules ou
point-virgules : il faudrait juste réserve le backslash ou d'un caractère
conventionel non réservé :
- \\ pour le backslash \ lui même
- \| pour le pipe |
- \= pour le signe égal =
- \[ et \] pour les crochets [ et ]
- \{ et \} pour les accolades { et }
- \s (semicolon) pour le point-virgule ; et non pas \; afin de ne pas
entrer en conflit avec les point-virgules séparateurs par défaut des listes
non ordonnées d'OSM)Et pour le cas où des chaines déjà entre "guillemets" ou entre 'apostrophes' sont utilisées: - \q (quote) pour les guillemets doubles ASCII " - \a (apos) pour les guillemets doubles ASCII ' Rien de prévu pour les échappements Unicode (ceux qui y tiennent pourront ajouter \xNN ou \uNNNN ou \UNNNNNN), le but étant de coder directement les caractères du texte si possible et d'utiliser sinon les échappements plus compacts à deux caractères... Avec ça on a tout pour imiter JSON, mais en plus compact et sans distinguer les types numériques et chaines (il n'y a qu'un seul type d'atome : les chaînes). Les schémas qui voudraient distinguer les types d'atomes devraient coder ça dans les atomes-chaines par une convention comme "type:valeur" (un peut comme le fait PHP pour sérialiser ses données), par exemple "i:10" pour indiquer l'entier 10 (nombre de bits non limité), "n:10" pour le nombre flottant 10 (précision non limitée), "s:10" pour indiquer la chaîne "10", "n:" pour indiquer une valeur nil, "d:date" pour une date dans un format compatible ISO8601 (avec séparateurs de champs de date optionnels pour que ce soit encore plus compact)... Le 1 mai 2015 01:17, Philippe Verdy <[email protected]> a écrit : > Le 1 mai 2015 00:35, dHuy Pierre <[email protected]> a écrit : > >> @Verdy: Heureux de te voir enfin, j'étais presqu'étoné de ne pas te lire. >> Cette propal de nomenclature est vraiment bonne. >> > > Note: je n'ai pas voulu taper "gags" mais "tags" (mais sur le coup le > smartphone que j'ai utilisé temporairement, le temps d'une indisponibilité > du système sur PC, n'en a fait qu'à sa tête malgré plusieurs corrections > successives de ce mot, il a encore été remplacé contre ma volonté lors de > l'envoi...) > > Personnellement je n'ai jamais aimé le fait de mêler deux types de > séparateurs dans les tags lanes, c'est très peu lisible et trompeur. Et > j'aurais préféré un codage de type JSON (mais encore un peu plus compact), > sans aucun point-virgule (sauf si la structure principale est celle d'une > liste non ordonnée: aucun point-virgule dans les éléments) > > Bref si on veut tout mettre dans un seul tag, permettre alors l'usage des > accolades, et dans ce cas dans les accolades permettre d'utilier > guillements et apostrophes ASCII pour encadrer des chaines (mais ne > contenant aucun point-virgule qui devraient utiliser un échappement) > > Les valeurs structurées et sous-structures ne seraient que des listes non > ordonnées (entre accolades, séparées par des pipes ou virgules), ou > ordonnées/indexés (entre crochets, séparées aussi par des pipes, avec un > éventuel signe égal pour nommer/indexer le champ), et contrairement à JSON, > les guillemets seraient presque toujours évitables, et il n'y aurait qu'un > seul type d'atome: les chaines, et pas de nombres en tant que tels > > Les séparateurs seraient également évitables s'il y a des crochets ou > accolades avant ou après, pour que ce soit encore plus compact. Pour cet > exemple cela donnerait: > > operator={[TDF{FM|FH}][Opérateur privé{PMR}][SNCF{GSM R}][FREE > MOBILE{UMTS 900|UMTS 2100|LTE 2600}]} > > Mais puisqu'ici la structure externe est une liste non ordonnée, on peut > aussi éviter les accolades externes et alors utiliser les points-virgules > habituels d'OSM, et supprimer aussi les crochets encadrant chaque élément > de la liste non ordonnée quant ils sont eux-même des listes ordonnées: > > operator=TDF{FM|FH};Opérateur privé{PMR};SNCF{GSM R};FREE MOBILE{UMTS 900|UMTS > 2100|LTE 2600} > > Et voilà alors notre format JSON-like, ultra compact, adapté pour OSM, > mais toujours très lisible ! > >
_______________________________________________ Talk-fr mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-fr
