¿Qué alternativas utilizables a la sintaxis XML conoces?

Question

Para mí utilizable significa que:

• se está utilizando en tiempo real, Wold
• cuenta con el apoyo de herramientas. (Al menos algunos sencillo editor)
• que tiene una sintaxis legible por humanos (no hay paréntesis angulares favor)

También quiero que sea lo más cerca posible de XML como sea posible, es decir, debe haber un apoyo para los atributos, así como para propiedades Entonces, no YAML por favor. Actualmente, solo me viene a la mente un lenguaje coincidente: JSON. ¿Conoces alguna otra alternativa?

Answer 1

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 se me ocurre nada que XML pueda hacer que YAML no puede, 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, realmente no "agregan" nada ... es solo un atajo de nota para escribir algo como un atributo del nodo en lugar de ponerlo en su propio hijo nodo. Pero si le gusta esa conveniencia, a menudo puede emularla con las listas/hashes en línea de YAML. Por ejemplo:

<!-- 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 nodo dos veces, combinado con la libertad de toda la camada escuadra angular hace YAML 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.

Answer 2

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.

Answer 3

Recomendaría JSON ... pero como ya lo mencionó quizás debería echar un vistazo al Google protocol buffers.

Editar: Los búferes de protocolo están hechos para ser usados ​​programáticamente (hay enlaces para C++, java, python ...) por lo que pueden no ser adecuados para su propósito.

Answer 4

Creo que Clearsilver es una muy buena alternativa. Incluso tienen una página de comparación here y una lista de projects que lo utilizan

Answer 5

Jeff escribió acerca de esta here y here. Eso debería ayudarte a comenzar.

Answer 6

Sus exigencias 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 usar XML? Nunca deberías tener que leer XML (aparte de la depuración, supongo), hay una cantidad absurda de herramientas para ello.

Casi todo lo que no es XML no va a ser tan ampliamente utilizado, por lo que habrá menos soporte de herramienta.

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 debería transformarse en matrices nativas/dicts/variables/lo que sea).

Oh, sí encuentran JSON ahora más agradable para analizar de XML: Lo he utilizado en Javascript, y el módulo de simplejson Python - alrededor de un comando y está muy bien transformarse en un diccionario de Python nativo, o un objeto Javascript (¡así el nombre!)

Answer 7

Si eres alérgico a los soportes angulares, entonces JSON, HDF (ClearSilver) y OGDL son los únicos que conozco de forma directa.

Después de un poco de google, también encontré una lista de alternativas aquí:
http://web.archive.org/web/20060325012720/www.pault.com/xmlalternatives.html

Answer 8

yo sepa, 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.

Answer 9

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

Answer 10

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í misma puede no ser tan agradable, si se compara con los pares clave-valor, p. 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 tabla hash en AJAX entre PHP y JavaScript y el formato que he desarrollado, se llama ProgFTE (Programador friendly texto Exchange) 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 aplicación ProgFTE como parte de la Biblioteca de Ruby Kibuvits: http://rubyforge.org/projects/kibuvits/

Answer 11

YAML es extremadamente plenamente las funciones y, en general formato legible por humanos, pero es talón de Aquiles es la complejidad como se demuestra por los carriles v las vulnerabilidades 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. Le recomiendo cualquiera que busque en YAML comprobarlo:

https://github.com/mojombo/toml

Answer 12

Para el almacenamiento de datos de código similar, LES (Loyc Expresión Sintaxis) 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; 
    } 
); 

Aunque todavía no tiene una gran herramienta de apoyo; actualmente, la única biblioteca LES es para C#. Actualmente, solo se conoce una aplicación que usa LES: LLLPG. Es compatible con "atributos", pero son como atributos de C# o anotaciones de Java, no atributos XML.

En teoría se podría utilizar para LES datos o marcado, pero no hay estándares para 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 }; 

Answer 13

Hay AXON que cubren el 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 combinación de datos XML y JSON-como-como.

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 biblioteca de Python ahora pyaxon.

Answer 14

TL; DR

Prolog no se ha 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

programadores a menudo "olvidan" lo que en realidad se compone de 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: DTD schema language, XSD schema language, XSLT transformation language, RNG schema language y XPath (más XQuery) idiomas: todos ellos son parte integrante 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. Por no mencionar las múltiples peculiaridades y errores de los populares análisis, algunos que conducen a problemas de seguridad notables como https://en.wikipedia.org/wiki/XML_external_entity_attack.

Por lo tanto, buscando una XML alternativa 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 de 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, tuvo el famoso screwed up debido a 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 :)