On dirait que tu dis ça comme si ça contredisait mon commentaire.
Comparer une twingo avec une 206 ce n’est pas problématique. Comparer la voiture, la caisse et le siège c’est problématique.
Pour celui qui fabrique la caisse ou le siège, la spécifications pour la caisse ou le siège couvrent l’ensemble du besoin. À son niveau, une caisse ou un siège c’est un ensemble cohérent. Pour celui qui assemble la voiture, sa spécification contient la caisse en question et le siège en question.
Bien sûr que le siège est lié à la caisse.
À aucun moment tu ne me contredis. Je rappelle simplement qu’il est possible de concevoir une spécification qui repose sur une autre spécification pour décrire le format des champs, et d’autres spécifications pour décrire tel ou tel type de donnée. On ne compare pas un format comme SQLite à CSV ou ASCII Delimited Text. Là si quelqu’un compare SQLite à CSV ou ASCII Delimited Text, il va avoir des problèmes. CSV ou ASCII Delimited Text c’est le format pour les champs, pas l’ensemble.
À ce que je sache, ni JSON, ni YAML, ni XML ne redéfinissent les standards pour formater les caractères, ils reposent sur des standards établi. Quand XML réutilise base64 pour stockent les blob, la spécification XML repose précisément sur une autre spécification. Idem pour les autres formats qui reposeraient sur uuencode pour les blobs. J’avais cité les dates au format ISO 8601, c’est normal pour une spécification de se reposer dessus.
Tu peux très bien faire face à une spécification qui repose sur UTF-8, ASCII Delimited Text, base64 et ISO 8601 et d’autres trucs de ce genre. La comparaison avec une spécification riche ne se portera pas sur ASCII Delimited Text uniquement, ce ne serait pas juste. Bon, même si on sera sûrement d’accord sur le fait qu’il est peut-être dommage de réinventer la roue alors que d’autres ont travaillé dur sur tous les cas particuliers auxquels on ne pense pas.
Ce fil de discussion tourne autour d’un problème de partie et de tout. Qu’au moins les comparaisons soient faites avec ce qui est comparable !
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Mal
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal En finir avec CSV ou Excel pour échanger des données. Évalué à 4. Dernière modification le 08 octobre 2020 à 22:04.
On dirait que tu dis ça comme si ça contredisait mon commentaire.
Comparer une twingo avec une 206 ce n’est pas problématique. Comparer la voiture, la caisse et le siège c’est problématique.
Pour celui qui fabrique la caisse ou le siège, la spécifications pour la caisse ou le siège couvrent l’ensemble du besoin. À son niveau, une caisse ou un siège c’est un ensemble cohérent. Pour celui qui assemble la voiture, sa spécification contient la caisse en question et le siège en question.
Bien sûr que le siège est lié à la caisse.
À aucun moment tu ne me contredis. Je rappelle simplement qu’il est possible de concevoir une spécification qui repose sur une autre spécification pour décrire le format des champs, et d’autres spécifications pour décrire tel ou tel type de donnée. On ne compare pas un format comme SQLite à CSV ou ASCII Delimited Text. Là si quelqu’un compare SQLite à CSV ou ASCII Delimited Text, il va avoir des problèmes. CSV ou ASCII Delimited Text c’est le format pour les champs, pas l’ensemble.
À ce que je sache, ni JSON, ni YAML, ni XML ne redéfinissent les standards pour formater les caractères, ils reposent sur des standards établi. Quand XML réutilise base64 pour stockent les blob, la spécification XML repose précisément sur une autre spécification. Idem pour les autres formats qui reposeraient sur
uuencodepour les blobs. J’avais cité les dates au format ISO 8601, c’est normal pour une spécification de se reposer dessus.Tu peux très bien faire face à une spécification qui repose sur UTF-8, ASCII Delimited Text, base64 et ISO 8601 et d’autres trucs de ce genre. La comparaison avec une spécification riche ne se portera pas sur ASCII Delimited Text uniquement, ce ne serait pas juste. Bon, même si on sera sûrement d’accord sur le fait qu’il est peut-être dommage de réinventer la roue alors que d’autres ont travaillé dur sur tous les cas particuliers auxquels on ne pense pas.
Ce fil de discussion tourne autour d’un problème de partie et de tout. Qu’au moins les comparaisons soient faites avec ce qui est comparable !
ce commentaire est sous licence cc by 4 et précédentes