Quelles alternatives utilisables à la syntaxe XML connaissez-vous ?[fermé]
https://stackoverflow.com/questions/51492
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Pour moi utilisable signifie que:
- il est utilisé dans le monde réel
- il prend en charge les outils.(au moins un simple éditeur)
- il a une syntaxe lisible par l'homme (pas de crochets angulaires s'il vous plaît)
Je veux aussi qu'il soit aussi proche que possible de XML, c'est-à-direil doit y avoir un support pour les attributs ainsi que pour les propriétés.Donc non YAML s'il te plaît.Actuellement, une seule langue correspondante me vient à l'esprit : JSON.Connaissez-vous d'autres alternatives ?
La solution
YAML est un sur-ensemble à 100 % de JSON, cela n'a donc aucun sens de rejeter YAML et d'envisager ensuite JSON à la place.YAML fait tout ce que JSON fait, mais YAML donne bien plus aussi (comme des références).
Je ne vois rien que XML puisse faire que YAML ne puisse faire, sauf valider un document avec une DTD, ce qui, d'après mon expérience, n'a jamais valu la surcharge.Mais YAML est bien plus rapide et plus facile à saisir et à lire que XML.
Quant aux attributs ou aux propriétés, si on y réfléchit, ils n'« ajoutent » vraiment rien...c'est juste un raccourci de notation pour écrire quelque chose comme attribut du nœud au lieu de le placer dans son propre nœud enfant.Mais si vous aimez cette commodité, vous pouvez souvent l'émuler avec les listes/hachages en ligne de YAML.Par exemple:
<!-- XML -->
<Director name="Spielberg">
<Movies>
<Movie title="Jaws" year="1975"/>
<Movie title="E.T." year="1982"/>
</Movies>
</Director>
# YAML
Director:
name: Spielberg
Movies:
- Movie: {title: E.T., year: 1975}
- Movie: {title: Jaws, year: 1982}
Pour moi, le luxe de ne pas avoir à écrire deux fois chaque balise de nœud, combiné à la liberté de tous les supports angulaires, fait de YAML un choix privilégié.J'aime aussi le manque d'attributs de balises formelles, car cela m'a toujours semblé être une zone grise de XML qui introduisait inutilement deux ensembles de syntaxe (à la fois lors de l'écriture et du parcours) pour essentiellement le même concept.YAML supprime complètement cette confusion.
Autres conseils
JSON est une très bonne alternative, et il existe des outils pour cela dans plusieurs langues.Et c'est vraiment facile à utiliser dans les clients Web, car il s'agit de javascript natif.
j'ai trouvé Expressions S être un excellent moyen de représenter des données structurées.C'est un format très simple, facile à générer et à analyser.Il ne prend pas en charge les attributs, mais comme YAML et JSON, ce n'est pas nécessaire.Les attributs sont simplement un moyen pour XML de limiter la verbosité.Les formats plus simples et plus propres n’en ont tout simplement pas besoin.
TL;DR
Prolog n'a pas été mentionné ici, mais c'est le meilleur format que je connaisse pour représenter des données.Les programmes Prolog décrivent essentiellement des bases de données, avec des relations complexes entre les entités.Prolog est extrêmement simple à analyser, son seul rival étant probablement les expressions S dans ce domaine.
Version complète
Les programmeurs « oublient » souvent en quoi consiste réellement XML.Se référant généralement à un très petit sous-ensemble de ce dont il s’agit.XML est un format très complexe, avec au moins ces parties : Langage de schéma DTD, Langage de schéma XSD, Langage de transformation XSLT, Langage de schéma RNG et XPath (plus XQuery) - ils font tous partie intégrante du standard XML.De plus, il existe des apocryphes comme E4X.Chacun d'entre eux ayant sa propre version, pas mal de chevauchements, d'incompatibilités, etc.Très peu d’analyseurs XML dans la nature les implémentent tous.Sans parler des multiples bizarreries et bugs des analyses populaires, certains conduisant à des problèmes de sécurité notables comme https://en.wikipedia.org/wiki/XML_external_entity_attack .
Par conséquent, la recherche d'un fichier XML alternative n'est pas une très bonne idée.Vous ne voulez probablement pas du tout vous occuper de XML.
YAML est probablement la deuxième pire option.Ce n'est pas aussi gros que XML, mais il a également été conçu pour tenter de couvrir toutes les bases...plus de dix fois chacun...de manières différentes et uniques que personne ne pourrait jamais imaginer.Je n'ai pas encore entendu parler d'un analyseur YAML fonctionnant correctement.Ruby, le langage qui utilise beaucoup YAML, avait la célèbre foiré à cause de ça.Tous les analyseurs YAML que j'ai vus à ce jour sont des copies de Libyeml, qui est lui-même un type d'analyseur écrit à la main (et non généré à partir d'une description formelle), avec un code dont l'exactitude est très difficile à vérifier (fonctions qui s'étendent sur des centaines de lignes avec un flux de contrôle alambiqué).Comme cela a déjà été mentionné, il contient entièrement du JSON...en plus d'une poignée de techniques de codage Unicode...à l'intérieur du même document, et probablement un tas d'autres choses dont vous ne voulez pas entendre parler.
JSON, en revanche, est complètement différent des deux autres.Vous pouvez probablement écrire un analyseur JSON en attendant le téléchargement de l'artefact de l'analyseur JSON depuis votre Maven Nexus.Il ne peut pas faire grand-chose, mais au moins vous savez de quoi il est capable.Pas de surprises.(Sauf quelques divergences liées aux caractères qui s'échappent dans les chaînes et au double encodage).Aucun exploit secret.Vous ne pouvez pas y écrire de commentaires.Les chaînes multilignes semblent mauvaises.Quoi que vous entendiez par distinction entre propriétés et attributs, vous pouvez l'implémenter à l'aide de dictionnaires plus imbriqués.
Supposons que vous souhaitiez réparer ce qui a fait du tort à XML...eh bien, alors les trucs populaires comme YAML ou JSON ne le feront pas.D’une manière ou d’une autre, la mode et la pensée rationnelle se sont séparées dans la programmation au milieu des années 70.Vous devrez donc revenir là où tout a commencé avec McCarthy, Hoare, Codd et Kowalski, déterminer ce que vous essayez de représenter, puis voir quelle est la meilleure technique de représentation qui existe pour tout ce que vous êtes. j'essaie de représenter :)
Je recommanderais JSON...mais comme tu l'as déjà mentionné, tu devrais peut-être y jeter un œil Tampons du protocole Google.
Modifier:Les tampons de protocole sont conçus pour être utilisés par programme (il existe des liaisons pour C++, Java, Python...), ils peuvent donc ne pas convenir à votre objectif.
Vos demandes sont un peu impossibles..Vous voulez quelque chose de proche de XML, mais rejetez probablement l'équivalent le plus proche qui n'a pas de support angulaire (YAML).
Même si cela ne me plaît pas, pourquoi ne pas simplement utiliser XML ?Vous ne devriez jamais avoir à lire du XML (à part le débogage, je suppose), il existe une quantité absurde d'outils pour cela.
Presque tout ce qui n'est pas XML ne sera pas aussi largement utilisé, il y aura donc moins de support d'outils.
JSON est probablement à peu près équivalent, mais il est à peu près tout aussi illisible.mais encore une fois, vous ne devriez jamais avoir à le lire (chargez-le dans la langue que vous utilisez, et il doit être transformé en tableaux/dicts/variables/quoi que ce soit natifs).
Oh, je trouve JSON loin plus agréable à analyser que XML :Je l'ai utilisé en Javascript et le module simplejson Python - environ une commande et il est joliment transformé en un dict Python natif, ou en un objet Javascript (d'où le nom !)
Il y a AXONE qui couvrent le meilleur de XML et JSON.Expliquons cela dans plusieurs exemples.
AXON pourrait être considéré comme une forme plus courte de données XML.
XML
<person>
<name>Frank Martin</name>
<age>32</age>
</person>
AXONE
person{
name{"Frank Martin"}
age{32}}
ou
person
name:
"Frank Martin"
age:
32
XML
<person name="Frank Martin" age="32" />
AXONE
person{name:"Frank Martin" age:32}
ou
person
name: "Frank Martin"
age: 32
AXON contient une certaine forme de JSON.
JSON
{"name":"Frank Martin" "age":32 "birth":"1965-12-24"}
AXONE
{name:"Frank Martin" age:32 birth:1965-12-24}
AXON peut représenter une combinaison de données de type XML et JSON.
AXONE
table {
fields {
("id" "int") ("val1" "double") ("val2" "int") ("val3" "double")
}
rows {
(1 3.2 123 -3.4)
(2 3.5 303 2.4)
(3 2.3 235 -1.2)
}
}
ou
table
fields
("id" "int")
("val1" "double")
("val2" "int")
("val3" "double")
rows
(1 3.2 123 -3.4)
(2 3.5 303 2.4)
(3 2.3 235 -1.2)
La bibliothèque python est disponible pyaxon maintenant.
Je pense Argent clair est une très bonne alternative.Ils ont même une page de comparaison ici et une liste de projets qui l'utilisent
Pour stocker des données de type code, LES (Loyc Expression Syntax) est une alternative naissante.J'ai remarqué que beaucoup de gens utilisent XML pour des constructions de type code, telles que des systèmes de construction prenant en charge les conditions, les invocations de commandes, parfois même les boucles.Ce genre de choses semblent naturelles dans les LES :
// LES code has no built-in meaning. This just shows what it looks like.
[DelayedWrite]
Output(
if version > 4.0 {
$ProjectDir/Src/Foo;
} else {
$ProjectDir/Foo;
}
);
Cependant, il ne dispose pas encore d'un excellent support d'outils ;actuellement, la seule bibliothèque LES est pour C#.Actuellement, une seule application est connue pour utiliser LES : LLLPG.Il prend en charge les "attributs", mais ils ressemblent aux attributs C# ou aux annotations Java, pas aux attributs XML.
En théorie, vous pouvez utiliser LES pour les données ou le balisage, mais il n'existe aucune norme sur la manière de procéder :
body {
'''Click here to use the World's '''
a href="http://google.com" {
strong "most popular"; " search engine!"
};
};
point = (2, -3);
tasteMap = { "lemon" -> sour; "sugar" -> sweet; "grape" -> yummy };
Si vous êtes allergique aux crochets angulaires, alors JSON, HDF (ClearSilver), et OGDL sont les seuls que je connais par hasard.
Après quelques recherches sur Google, j'ai également trouvé une liste d'alternatives ici :
http://web.archive.org/web/20060325012720/www.pault.com/xmlalternatives.html
YAML est un format extrêmement complet et généralement lisible par l'homme, mais son problème d'Achille est sa complexité, comme le démontrent les vulnérabilités Rails que nous avons constatées cet hiver.En raison de son omniprésence dans Ruby en tant que langage de configuration, Tom Preston-Werner, de renommée Github, a décidé de créer une alternative sensée baptisée TOML.Il a immédiatement gagné en popularité et dispose d’un excellent support d’outils.Je recommande fortement à tous ceux qui consultent YAML de le vérifier :
AFAIK, JSON et YAML sont exactement équivalents en termes de structure de données.YAML a juste moins de crochets, de guillemets et autres.Je ne vois donc pas comment vous rejetez l’un et gardez l’autre.
De plus, je ne vois pas en quoi les crochets angulaires de XML sont moins "lisibles par l'homme" que les crochets, les accolades et les guillemets de JSON.
Il existe véritablement de nombreuses alternatives au XML, mais le principal problème de beaucoup d'entre elles semble être que les bibliothèques ne sont peut-être pas disponibles pour tous les langages de choix et que les bibliothèques sont relativement laborieuses à mettre en œuvre.
L'analyse d'une structure arborescente elle-même peut ne pas être si agréable, si on la compare à des paires clé-valeur, par ex.tables de hachage.Si une instance de table de hachage répond à l'exigence selon laquelle toutes ses clés sont des chaînes et que toutes ses valeurs sont des chaînes, alors il est relativement simple d'implémenter hashtable2string() et string2hashtable().
J'utilise la sérialisation des tables de hachage en AJAX entre PHP et JavaScript et le format que j'ai développé s'appelle ProgFTE (Programmer Friendly text Exchange) et est décrit à l'adresse :
http://martin.softf1.com/g/n//a2/doc/progfte/index.html
On peut trouver une version Ruby de l'implémentation ProgFTE dans la bibliothèque Ruby de Kibuvits :http://rubyforge.org/projects/kibuvits/
