• [^] # Re: XML sapu et autres billevesées

    Posté par . 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é à 1.

    Ton champs comment est un gros hack degueu

    Oui, c’est pas terrible. Mais à part pour des fichiers de conf, les commentaires, ça ne sert pas à grand chose. Si tu m’envoies en communication M2M des xmls avec des commentaires, c’est moi qui vais hurler :).

    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.

    J’en déduis que le concept de list<pair<int,int> > est interdit chez toi ?

    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 à :

    <root>
     <apples>
     <apple type="golden" count="12">
     <apple type="pinklady" count="23">
     </apples>
     <oranges>
    

    (je te laisse compléter). Elle est où la différence ?

    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.

    <?xml version="1.0"?>
    <toto><![CDATA[écrire ]]]]><![CDATA[> c’est compliqué]]></toto>
    

    C’est gros, mais pourtant, plusieurs évaluateurs xpath ne me donnent pas le même résultat pour toto/text()...

    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.

    Je suppose que tu veux dire que la (les) feuille à xsd à utiliser est déclarée dans le document. Oui, c’est pratique car ça permet à un tiers de valider en partie les données. Par contre, c’est insuffisant car tout n’est pas exprimable avec. Se reposer uniquement là-dessus, c’est casse gueule. Mais oui, c’est pratique. Par contre, signer le document (par exemple) casse cette validation... Tout embarquer dans le même document ça n’a pas que des avantages.

    Cet echange de document n'arrive pas nécessairement par http — batch job, config offline, que sais je encore.

    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).

    Après, oui, XML a aujourd’hui un écosystème beaucoup plus riche (et j’avais déjà souligné certains points dès le départ). JSON manque énormément de standardisation à ce niveau. Mais ces points peuvent être ajoutés, en partant d’un format qui est plus simple et plus efficace que XML.

    Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0