Non, pas peu, ca manque, point à la ligne. En tout cas, si tu veux l'utiliser en remplacement de xml.
Ton champs comment est un gros hack degueu:
- tu ne peux avoir qu'un champs comment par objet. Si tu veux mettre un commentaire par champs, ben tu l'as dans l'os
- si ton objet mappe a déjà un champ comment, tu l'as dans l'os. Oui, on va pas se voiler la face, 95% des objets json sont un mapping direct d'objet/structure en mémoire. C'est tout l'intérêt du format, il puise sa spec dans ce pattern, et des que tu dévies de ca, tu perds une grosse partie de l'intérêt de json. Alors, oui, certains langage permettent un mapping compliqué, mais pas tous.
l’ordre des attributs ne l’est pas non plus en xml. Cf mon autre réponse plus loin à ce sujet quand tu as besoin d’un ordre.
Les attributs, non, mais on s'en fout, ca a jamais dérangé persone. L'ordre des éléments par contre est crucial, cf l'exemple du xhtml donne plus haut. Ou le cas de la config modifiée par un process puis reserializee (genre un pom par exemple. Ca fait pas plaisir de voir le bordel dans son pom après une release (c'est ce qui m'a fait partir sur du xml la dernière fois que j'ai écrit un outil du genre).
Ta technique de remplacer l'objet par un array est affreuse, tu changes complètement la semantique de l'objet, et perd la contrainte d'unicité des champs — ah ben tiens, un truc qui n'est pas spécifié par json, et qui est parfaitement specifie par xml (donc pas du tout ambiguë).
Le contrat implicite de json, c'est que ca mappe directement un objet en mémoire, et que donc chaque champ est unique dans son parent.
Le problème c'est que c'est implicite, donc pas spécifié. Techniquement, c'est valide. En pratique, tu fais ca, tu vas recevoir un email vener du mec qui consomme ton document, parce que son mappeur lance une exception.
Perso tu m'envoie un objet avec ta technique "un array d'objet a un seul champ", tu vas recevoir un email,pas piqué des hannetons de ma part. Ca fout en l'air tout mon mapping, et quitte à me prendre la tête sur le mapping, je préfère encore me taper du xml.
Je suis curieux de savoir ce que tu appelles « bien crade »
Devoir stocker des metadata dans l'objet lui même. Ton champs s,ドル il a rien à faire sur l'objet lui même, il n'en fait pas partit, il sert juste à décrire l'objet pour une autre partie du système. Typiquement, tu vas utiliser un attribut pour ca:
<objecttype="com.foo.Bar"><fieldname="s$"type="Integer">42</field><fieldname="anArray"type="ArrayList">etc je te laisse fermer les balise, c'est pete couille sur un ipad, le backticks sont déjà suffisamment chier à taper.
Et de la nécessité des [CDATA] suivant le contenu, ce qui peut te péter pas mal d’outils qui n’en tiendront pas compte parce que ça te rajoute un nœud supplémentaire dans ton arbre dom...
Heu, ouais, enfin xml est largement spécifie, les autres outils doivent soit implémenter la spec (pas facile, certes), soit utiliser une lib qui le fait. Autant je veux bien comprendre que certains cas à la marge passent à la trappe (bug, tout ca), autant zapper les cdata, c'est un peu gros quand même.
Ça existe déjà. Par contre, ce n’est pas standardisé comme peut l’être xsd. Et c’est effectivement un problème pour l’instant.
J'ai pas l'impression que tu comprends l'intérêt d xml dans ce genre de choses. Plusieurs choses:
- la feuilles xsd est incluse DANS le document. T'envoies un doc xml a un process, et il peut valider la structure de l'arbre tout seul, et le rejeter s'il est pas bon. Ou le rejeter parce qu'il n'as pas la bonne xsd.
- Cet echange de document n'arrive pas nécessairement par http — batch job, config offline, que sais je encore.
Y'a un clair besoin d'embarquer des metadata dans le document lui même. Sans ca, y'a un paquet de choses que tu ne peux pas faire - tout ce qui tourne autour de la validation, ou tous les cas où t'as besoin de décrire un élément, mais ou cette description ne fait pas partie de l'objet lui même.
JSON ne supporte pas du tout ce cas. Et n'essaie pas, ni meme ne pretend. Si t'as besoin de meta donnees, va voir ailleurs. Et y'a pas de problème avec ca, tour le monde n'as pas besoin de ca. Mais pour ceux qui en ont besoin, c'est un besoin critique. Tout le monde ne fait pas des services grands public avec 15 deployments par jour, ou indisponibilité/bug veut dire "10 personnes ne peuvent pas poster une photo de chats".
ya des gens qui ecritvent des services qui ne peuvent pas se permettre de pondre un format incorrect, et pour qui la seule option dans ce cas est de refuser le traitement et lancer une alerte. C'est vachement plus chiant comme approche de development, mais ils ont pas le choix, c'est la seule solution au problème qu'ils doivent résoudre.
Entends moi bien, json est tres bien, et je l'utilise allègrement tous les jours. Mais quand je lit des trucs genre "JSON a tous les atouts pour le remplacer dans tous les domaines " je bondit un peu au plafond. Json est populaire parce qu'il est super simple et tres tolérant aux erreurs, on les passe sous silence, et on continue comme on peut. Cette approche marche tres bien pour beaucoup de monde. Mais c'est clairement inacceptable pour beaucoup d'autres personnes.
'Fin c'est comme si tu disais "les camionnettes, c'est vachement bien ca va remplacer tous les véhicules de livraison, les 36 tonnes c'est vachement plus chiant à conduire". Ca répond juste pas aux même problématiques.
Le,problème, c'est qu'au début des années 2000, on a vendu des 36 tonnes a tout le monde, et la camionnette n'a été inventée qu'après, alor,s oui, c'est sur que livrer un pauvre bouquin a un gars dans un patelin paume en 36 tonnes, c'est relou. Ca veut pas dire que les 36 tonnes vont disparaître.
[^] # Re: XML sapu et autres billevesées
Posté par groumly . En réponse à la dépêche SPARQL, le SQL du Web, et Linked Data Fragment : le point sur le requêtage du Web. Évalué à 5.
Non, pas peu, ca manque, point à la ligne. En tout cas, si tu veux l'utiliser en remplacement de xml.
Ton champs comment est un gros hack degueu:
- tu ne peux avoir qu'un champs comment par objet. Si tu veux mettre un commentaire par champs, ben tu l'as dans l'os
- si ton objet mappe a déjà un champ comment, tu l'as dans l'os. Oui, on va pas se voiler la face, 95% des objets json sont un mapping direct d'objet/structure en mémoire. C'est tout l'intérêt du format, il puise sa spec dans ce pattern, et des que tu dévies de ca, tu perds une grosse partie de l'intérêt de json. Alors, oui, certains langage permettent un mapping compliqué, mais pas tous.
Les attributs, non, mais on s'en fout, ca a jamais dérangé persone. L'ordre des éléments par contre est crucial, cf l'exemple du xhtml donne plus haut. Ou le cas de la config modifiée par un process puis reserializee (genre un pom par exemple. Ca fait pas plaisir de voir le bordel dans son pom après une release (c'est ce qui m'a fait partir sur du xml la dernière fois que j'ai écrit un outil du genre).
Ta technique de remplacer l'objet par un array est affreuse, tu changes complètement la semantique de l'objet, et perd la contrainte d'unicité des champs — ah ben tiens, un truc qui n'est pas spécifié par json, et qui est parfaitement specifie par xml (donc pas du tout ambiguë).
Le contrat implicite de json, c'est que ca mappe directement un objet en mémoire, et que donc chaque champ est unique dans son parent.
Le problème c'est que c'est implicite, donc pas spécifié. Techniquement, c'est valide. En pratique, tu fais ca, tu vas recevoir un email vener du mec qui consomme ton document, parce que son mappeur lance une exception.
Perso tu m'envoie un objet avec ta technique "un array d'objet a un seul champ", tu vas recevoir un email,pas piqué des hannetons de ma part. Ca fout en l'air tout mon mapping, et quitte à me prendre la tête sur le mapping, je préfère encore me taper du xml.
Devoir stocker des metadata dans l'objet lui même. Ton champs s,ドル il a rien à faire sur l'objet lui même, il n'en fait pas partit, il sert juste à décrire l'objet pour une autre partie du système. Typiquement, tu vas utiliser un attribut pour ca:
Heu, ouais, enfin xml est largement spécifie, les autres outils doivent soit implémenter la spec (pas facile, certes), soit utiliser une lib qui le fait. Autant je veux bien comprendre que certains cas à la marge passent à la trappe (bug, tout ca), autant zapper les cdata, c'est un peu gros quand même.
J'ai pas l'impression que tu comprends l'intérêt d xml dans ce genre de choses. Plusieurs choses:
- la feuilles xsd est incluse DANS le document. T'envoies un doc xml a un process, et il peut valider la structure de l'arbre tout seul, et le rejeter s'il est pas bon. Ou le rejeter parce qu'il n'as pas la bonne xsd.
- Cet echange de document n'arrive pas nécessairement par http — batch job, config offline, que sais je encore.
Y'a un clair besoin d'embarquer des metadata dans le document lui même. Sans ca, y'a un paquet de choses que tu ne peux pas faire - tout ce qui tourne autour de la validation, ou tous les cas où t'as besoin de décrire un élément, mais ou cette description ne fait pas partie de l'objet lui même.
JSON ne supporte pas du tout ce cas. Et n'essaie pas, ni meme ne pretend. Si t'as besoin de meta donnees, va voir ailleurs. Et y'a pas de problème avec ca, tour le monde n'as pas besoin de ca. Mais pour ceux qui en ont besoin, c'est un besoin critique. Tout le monde ne fait pas des services grands public avec 15 deployments par jour, ou indisponibilité/bug veut dire "10 personnes ne peuvent pas poster une photo de chats".
ya des gens qui ecritvent des services qui ne peuvent pas se permettre de pondre un format incorrect, et pour qui la seule option dans ce cas est de refuser le traitement et lancer une alerte. C'est vachement plus chiant comme approche de development, mais ils ont pas le choix, c'est la seule solution au problème qu'ils doivent résoudre.
Entends moi bien, json est tres bien, et je l'utilise allègrement tous les jours. Mais quand je lit des trucs genre "JSON a tous les atouts pour le remplacer dans tous les domaines " je bondit un peu au plafond. Json est populaire parce qu'il est super simple et tres tolérant aux erreurs, on les passe sous silence, et on continue comme on peut. Cette approche marche tres bien pour beaucoup de monde. Mais c'est clairement inacceptable pour beaucoup d'autres personnes.
'Fin c'est comme si tu disais "les camionnettes, c'est vachement bien ca va remplacer tous les véhicules de livraison, les 36 tonnes c'est vachement plus chiant à conduire". Ca répond juste pas aux même problématiques.
Le,problème, c'est qu'au début des années 2000, on a vendu des 36 tonnes a tout le monde, et la camionnette n'a été inventée qu'après, alor,s oui, c'est sur que livrer un pauvre bouquin a un gars dans un patelin paume en 36 tonnes, c'est relou. Ca veut pas dire que les 36 tonnes vont disparaître.