Oui, c’est pas terrible. Mais à part pour des fichiers de conf, les commentaires, ça ne sert pas à grand chose
Ben ouais, mais quand tu parles de remplacer xml dans tous les domaines, c'est un peu un gros,problème, tu penses pas?
J’en déduis que le concept de list > est interdit chez toi ?
Pas si ca correspond bien à la semantique du document.
Si la semantique du document, c'est un objet avec des champs, fourrer tous les champs dans un array n'est pas une bonne idee. Surtout si tu fais ca à cause d'une limitation de ton format de persistence.
Tu veux une liste ordonnée, c’est une array. Tu veux un tableau associatif, c’est un un objet. Dans ton xml, dès que tu as plusieurs types d’enfant, tu te retrouves souvent à :
Yen a pas de différence, tu modélise une liste d'objet, donc un array est la bonne structure. Mon problème est sur la technique que tu décrivais, de modifier fondamentalement la structure et semantique du document pour contourner une limite du format. Tu passes aussi allègrement sous silence le fait que répéter le même champs est non spécifié en json.
Ca contrevient clairement à la philosophie du format, mais est techniquement valide, donc on fait quoi?
Tout embarquer dans le même document ça n’a pas que des avantages.
J'ai jamais fait de signatures en xml, donc je vais te croire sur parole. Toujours est il que la discussion était "json peut facilement remplacer xml dans tous les domaines", et visiblement, c'est pas le cas. Ce cas tres courant est pas supporté, et ne vas pas pouvoir être supporté sans peter la compat avec l'existant.
Là c’est toi qui te limite complètement arbitrairement. Le transport est complètement agnostique aussi du point de vue json (même s’il est né sur le web et dans les navigateurs).
Ta spec ne dit absolument rien sur comment déclarer la feuille de validation offline, le seul exemple qu'elle donne est pour du transport http, en utilisant le content type header. Pour valider un document offline, y'a absolument rien dans ta spec.
[^] # 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é à 2.
Ben ouais, mais quand tu parles de remplacer xml dans tous les domaines, c'est un peu un gros,problème, tu penses pas?
Pas si ca correspond bien à la semantique du document.
Si la semantique du document, c'est un objet avec des champs, fourrer tous les champs dans un array n'est pas une bonne idee. Surtout si tu fais ca à cause d'une limitation de ton format de persistence.
Yen a pas de différence, tu modélise une liste d'objet, donc un array est la bonne structure. Mon problème est sur la technique que tu décrivais, de modifier fondamentalement la structure et semantique du document pour contourner une limite du format. Tu passes aussi allègrement sous silence le fait que répéter le même champs est non spécifié en json.
Ca contrevient clairement à la philosophie du format, mais est techniquement valide, donc on fait quoi?
J'ai jamais fait de signatures en xml, donc je vais te croire sur parole. Toujours est il que la discussion était "json peut facilement remplacer xml dans tous les domaines", et visiblement, c'est pas le cas. Ce cas tres courant est pas supporté, et ne vas pas pouvoir être supporté sans peter la compat avec l'existant.
Ta spec ne dit absolument rien sur comment déclarer la feuille de validation offline, le seul exemple qu'elle donne est pour du transport http, en utilisant le content type header. Pour valider un document offline, y'a absolument rien dans ta spec.