son - xml distingue entre mayusculas y minusculas
¿Qué alternativas usables a la sintaxis XML conoces? (14)
Creo que Clearsilver es una muy buena alternativa. Incluso tienen una página de comparación aquí y una lista de proyectos que la usan
Para mí utilizable significa que:
- está siendo utilizado en real-wold
- tiene herramientas de soporte. (al menos un editor simple)
- tiene sintaxis legible por humanos (sin paréntesis angulares por favor)
También quiero que sea lo más cercano posible a XML, es decir, debe haber compatibilidad con atributos y propiedades. Entonces, no YAML por favor. Actualmente, solo me viene a la mente un lenguaje coincidente: JSON . ¿Conoces alguna otra alternativa?
JSON es una muy buena alternativa, y hay herramientas para ello en varios idiomas. Y es muy fácil de usar en clientes web, ya que es JavaScript nativo.
AFAIK, JSON y YAML son exactamente equivalentes en términos de estructura de datos. YAML solo tiene menos corchetes y comillas y esas cosas. Entonces no veo cómo está rechazando uno y manteniendo el otro.
Además, no veo cómo los corchetes angulares de XML son menos "legibles por humanos" que los corchetes, las llaves y las comillas de JSON.
Recomendaría JSON ... pero como ya lo mencionó quizás debería echarle un vistazo a los buffers de protocolo de Google .
Edición: los búferes de protocolo están diseñados para ser utilizados de forma programática (existen enlaces para c ++, java, python ...) por lo que pueden no ser adecuados para su propósito.
Si eres alérgico a los corchetes angulares, entonces JSON, HDF (ClearSilver) y OGDL son los únicos que conozco de forma directa.
Después de buscar en Google, también encontré una lista de alternativas aquí:
http://web.archive.org/web/20060325012720/www.pault.com/xmlalternatives.html
Sus demandas son un poco imposibles. Desea algo parecido a XML, pero probablemente rechace el equivalente más cercano que no tenga paréntesis angulares (YAML).
Por mucho que no me guste, ¿por qué no simplemente usar XML? Nunca deberías tener que leer XML (aparte de la depuración, supongo), hay una cantidad absurda de herramientas para ello.
Prácticamente todo lo que no es XML no va a ser tan ampliamente utilizado, por lo que habrá menos soporte de herramientas.
JSON es probablemente equivalente, pero es prácticamente ilegible ... pero, de nuevo, nunca deberías tener que leerlo realmente (cárgalo en el idioma que estés usando, y se debe transformar en matrices / dictos / variables nativos) lo que sea).
Oh, encuentro que JSON es mucho más fácil de analizar que XML: lo he usado en Javascript, y en el módulo simplejson de Python, sobre un comando y está muy bien transformado en un dict nativo de Python, o un objeto Javascript (¡así es el nombre!)
He encontrado que S-Expressions es una gran manera de representar datos estructurados. Es un formato muy simple que es fácil de generar y analizar. No admite atributos, pero al igual que YAML y JSON, no es necesario. Los atributos son simplemente una forma de que XML limite la verbosidad. Los formatos más simples y limpios simplemente no los necesitan.
YAML es un superconjunto 100% de JSON, por lo que no tiene sentido rechazar YAML y luego considerar JSON en su lugar. YAML hace todo lo que hace JSON, pero YAML también ofrece mucho más (como referencias).
No puedo pensar en nada que XML pueda hacer que YAML no pueda, excepto para validar un documento con una DTD, que en mi experiencia nunca ha valido la pena. Pero YAML es mucho más rápido y fácil de escribir y leer que XML.
En cuanto a los atributos o propiedades, si lo piensas, en realidad no "agregan" nada ... es solo un atajo de nota para escribir algo como un atributo del nodo en lugar de ponerlo en su propio nodo hijo. Pero si le gusta esa conveniencia, a menudo puede emularla con las listas / hashes en línea de YAML. P.ej:
<!-- 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}
Para mí, el lujo de no tener que escribir cada etiqueta de nodo dos veces, combinada con la libertad de toda la arena angular, hace que YAML sea una opción preferida. También me gusta la falta de atributos formales de las etiquetas, ya que siempre me pareció que era un área gris de XML que introducía innecesariamente dos conjuntos de sintaxis (tanto al escribir como al atravesar) para esencialmente el mismo concepto. YAML elimina esa confusión por completo.
Existen muchas alternativas a XML, pero el principal problema con muchas de ellas parece ser que las bibliotecas pueden no estar disponibles para todos los idiomas de su elección y las bibliotecas son relativamente laboriosas de implementar.
Analizar una estructura de árbol en sí mismo puede no ser tan agradable, si se compara con los pares clave-valor, por ejemplo, tablas hash. Si una instancia de tabla hash cumple con el requisito de que todas sus claves son cadenas y todos sus valores son cadenas, entonces es relativamente poco laborioso implementar hashtable2string () y string2hashtable ().
He estado usando la serialización de tabla hash en AJAX entre PHP y JavaScript y el formato que he desarrollado se llama ProgFTE (Programador de intercambio de texto amigable) y se describe en:
http://martin.softf1.com/g/n//a2/doc/progfte/index.html
Uno puede encontrar una versión de Ruby de la implementación ProgFTE como parte de la Biblioteca Kibuvits Ruby: http://rubyforge.org/projects/kibuvits/
YAML tiene un formato extremadamente completo y generalmente legible para las personas, pero la curación de Aquiles es compleja, como lo demuestran las vulnerabilidades de Rails que vimos este invierno. Debido a su ubicuidad en Ruby como lenguaje de configuración, Tom Preston-Werner, de Github, se hizo famoso para crear una alternativa sensata llamada TOML. Obtuvo una tracción masiva de inmediato y tiene un gran soporte de herramientas. Recomiendo encarecidamente a cualquiera que mire a YAML échale un vistazo:
Existe AXON que cubre lo mejor de XML y JSON. Vamos a explicar eso en varios ejemplos.
AXON podría considerarse como una forma más corta de datos XML.
XML
<person>
<name>Frank Martin</name>
<age>32</age>
</person>
AXON
person{
name{"Frank Martin"}
age{32}}
o
person
name:
"Frank Martin"
age:
32
XML
<person name="Frank Martin" age="32" />
AXON
person{name:"Frank Martin" age:32}
o
person
name: "Frank Martin"
age: 32
AXON contiene alguna forma de JSON.
JSON
{"name":"Frank Martin" "age":32 "birth":"1965-12-24"}
AXON
{name:"Frank Martin" age:32 birth:1965-12-24}
AXON puede representar una combinación de datos similares a XML y JSON.
AXON
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)
}
}
No está disponible la pionera de la biblioteca de Python ahora.
TL; DR
Prolog no fue mencionado aquí, pero es el mejor formato que conozco para representar datos. Los programas de Prolog, esencialmente, describen bases de datos, con relaciones complejas entre entidades. Prolog está muerto, es simple de analizar, y probablemente su único rival sean las expresiones S en este dominio.
Versión completa
Los programadores a menudo "olvidan" en qué consiste XML. Por lo general, se refiere a un subconjunto muy pequeño de lo que es. XML es un formato muy complejo, con al menos estas partes: el lenguaje de esquema DTD , el lenguaje de esquema XSD , el lenguaje de transformación XSLT , el lenguaje de esquema RNG y los lenguajes XPath (más XQuery): todos ellos forman parte del estándar XML. Además, hay algunos apócrifos como E4X . Todos y cada uno de ellos tienen sus propias versiones, un poco de superposición, incompatibilidades, etc. Muy pocos analizadores XML en la naturaleza implementan todos ellos. Sin mencionar las múltiples peculiaridades y errores de los análisis populares, algunos de los cuales conducen a problemas de seguridad notables como https://en.wikipedia.org/wiki/XML_external_entity_attack .
Por lo tanto, buscar una alternativa XML no es una muy buena idea. Probablemente no quieras tratar con los gustos de XML en absoluto.
YAML es, probablemente, la segunda peor opción. No es tan grande como XML, pero también fue diseñado en un intento por cubrir todas las bases ... más de diez veces cada una ... de maneras diferentes y únicas que nadie podría concebir. Todavía tengo que escuchar sobre un analizador de YAML que funcione correctamente. Ruby, el lenguaje que usa mucho YAML, se hizo famoso por eso. Todos los analizadores YAML que he visto hasta la fecha son copias de libyaml , que es un analizador escrito a mano (no generado a partir de una descripción formal), con un código que es muy difícil de verificar para la corrección (funciones que abarcan cientos de líneas con flujo de control intrincado). Como ya se mencionó, contiene JSON por completo ... además de un puñado de técnicas de codificación Unicode ... dentro del mismo documento, y probablemente un montón de otras cosas que no quiere escuchar.
JSON, por otro lado, es completamente diferente a los otros dos. Probablemente pueda escribir un analizador JSON mientras espera la descarga del artefacto del analizador JSON desde su Maven Nexus. Puede hacer muy poco, pero al menos sabes de lo que es capaz. No hay sorpresas. (Excepto algunas discrepancias relacionadas con el escape de caracteres en la codificación de cadenas y dobles). Sin explotaciones encubiertas. No puedes escribir comentarios en él. Las cadenas multilíneas se ven mal. Sea lo que sea lo que quiera decir con la distinción entre propiedades y atributos, puede implementarlo mediante más diccionarios anidados.
Supongamos que, aunque quiere saber qué es lo que XML perjudicó ... bueno, las cosas populares como YAML o JSON no lo harán. De alguna manera, la moda y el pensamiento racional se separaron en la programación en algún momento a mediados de los años setenta. Por lo tanto, tendrás que regresar a donde todo comenzó con McCarthy, Hoare, Codd y Kowalski, descubrir qué es lo que estás tratando de representar, y luego ver cuál es la mejor técnica de representación para lo que sea que seas tratando de representar :)
Para almacenar datos tipo código, LES (Loyc Expression Syntax) es una alternativa en ciernes. Me he dado cuenta de que muchas personas usan XML para construcciones similares a códigos, como sistemas de compilación que admiten condicionales, invocaciones de comandos, a veces incluso bucles. Este tipo de cosas se ven naturales en 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;
}
);
Sin embargo, aún no cuenta con una gran herramienta de soporte; actualmente, la única biblioteca LES es para C #. Actualmente solo se sabe que una aplicación usa LES: LLLPG . Es compatible con "atributos", pero son como atributos de C # o anotaciones de Java, no atributos XML.
En teoría, puede usar LES para datos o marcado, pero no hay estándares sobre cómo hacerlo:
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 };