¿Qué alternativas utilizables a la sintaxis XML conoces?[cerrado]

StackOverflow https://stackoverflow.com/questions/51492

  •  09-06-2019
  •  | 
  •  

Pregunta

Para mí usable significa que:

  • se está utilizando en el mundo real
  • Tiene soporte para herramientas.(al menos algún editor simple)
  • tiene una sintaxis legible por humanos (sin corchetes angulares, por favor)

También quiero que sea lo más parecido posible a XML, es decir.debe haber soporte tanto para atributos como para propiedades.Así que no YAML por favor.Actualmente sólo me viene a la mente un idioma coincidente: JSON.¿Conoces otras alternativas?

¿Fue útil?

Solución

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 pueda, excepto validar un documento con una DTD, lo cual, según 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 bien, realmente no "añaden" nada...es solo un atajo de notación para escribir algo como un atributo del nodo en lugar de ponerlo en su propio nodo hijo.Pero si le gusta esa comodidad, 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, combinado con la libertad de toda la basura de soportes angulares, hace de YAML una opción preferida.De hecho, también me gusta la falta de atributos de etiquetas formales, ya que siempre me pareció un área gris de XML que introducía innecesariamente dos conjuntos de sintaxis (tanto al escribir como al recorrer) para esencialmente el mismo concepto.YAML elimina esa confusión por completo.

Otros consejos

JSON es una muy buena alternativa y existen herramientas para ello en varios idiomas.Y es realmente fácil de usar en clientes web, ya que es javascript nativo.

he encontrado Expresiones S ser una excelente 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 en que XML limita la verbosidad.Los formatos más simples y limpios simplemente no los necesitan.

TL;DR

Prolog no se mencionó aquí, pero es el mejor formato que conozco para representar datos.Los programas Prolog, esencialmente, describen bases de datos con relaciones complejas entre entidades.Prolog es muy sencillo de analizar, cuyo único rival probablemente sean las expresiones S en este dominio.

Versión completa

Los programadores a menudo "olvidan" en qué consiste realmente XML.Generalmente se refiere a un subconjunto muy pequeño de lo que es.XML es un formato muy complejo, con al menos estas partes: lenguaje de esquema DTD, lenguaje de esquema XSD, Lenguaje de transformación XSLT, lenguaje de esquema RNG y XPath (más XQuery): todos ellos son parte integrante del estándar XML.Además, hay algunos apócrifos como E4X.Todos y cada uno de ellos con sus propias versiones, bastantes solapamientos, incompatibilidades etc.Muy pocos analizadores XML existentes los implementan todos.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 un XML alternativa no es una muy buena idea.Probablemente no quieras lidiar con 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 uno...de maneras diferentes y únicas que nadie podría jamás concebir.Todavía tengo que oír hablar de un analizador YAML que funcione correctamente.Ruby, el lenguaje que usa mucho YAML, tenía fama de arruinado por eso.Todos los analizadores YAML que he visto hasta la fecha son copias de libia, que es en sí mismo un tipo de analizador escrito a mano (no generado a partir de una descripción formal), con un código cuya corrección es muy difícil de verificar (funciones que abarcan cientos de líneas con un flujo de control complicado).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 de las que no querrás oír hablar.

JSON, por otro lado, es completamente diferente a los otros dos.Probablemente pueda escribir un analizador JSON mientras espera descargar el 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 cadenas y codificación doble).Sin hazañas encubiertas.No puedes escribir comentarios en él.Las cadenas multilínea se ven mal.Independientemente de lo que quiera decir con distinción entre propiedades y atributos, puede implementarlo mediante más diccionarios anidados.

Supongamos que, aunque quisieras corregir lo que XML hizo mal...bueno, entonces las cosas populares como YAML o JSON no servirán.De alguna manera, la moda y el pensamiento racional se separaron en la programación a mediados de los años setenta.Entonces, tendrás que volver 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 que existe para lo que sea que seas. tratando de representar :)

Jeff escribió sobre esto aquí y aquí.Eso debería ayudarte a empezar.

Recomendaría JSON...pero como ya lo mencionaste tal vez deberías echarle un vistazo Búfers de protocolo de Google.

Editar:Los buffers de protocolo están diseñados para usarse mediante programación (hay enlaces para c++, java, python...), por lo que es posible que no sean adecuados para su propósito.

Tus demandas son un poco imposibles...Quiere algo parecido a XML, pero probablemente rechace el equivalente más cercano que no tenga corchetes angulares (YAML).

Por mucho que no me guste, ¿por qué no utilizar XML?Nunca deberías tener que leer XML (aparte de la depuración, supongo), hay una cantidad absurda de herramientas para ello.

Prácticamente cualquier cosa que no sea XML no será tan utilizada, por lo que habrá menos soporte para herramientas.

JSON probablemente sea equivalente, pero es prácticamente igualmente ilegible.pero, de nuevo, nunca deberías tener que leerlo (cárgalo en cualquier idioma que estés usando, y debería transformarse en matrices/dicts/variables/lo que sea nativo).

Oh, encuentro JSON lejos más agradable de analizar que XML:Lo he usado en Javascript y el módulo simplejson de Python: aproximadamente un comando y se transforma muy bien en un dictado nativo de Python o en un objeto de Javascript (¡de ahí el nombre!).

Hay AXÓN que cubren lo mejor de XML y JSON.Expliquemos 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>

AXÓN

person{
  name{"Frank Martin"}
  age{32}}

o 

person
  name:
    "Frank Martin"
  age:
    32

XML

<person name="Frank Martin" age="32" />

AXÓN

person{name:"Frank Martin" age:32}

o 

person
  name: "Frank Martin"
  age: 32

AXON contiene algún tipo de JSON.

JSON

{"name":"Frank Martin" "age":32 "birth":"1965-12-24"}

AXÓN

{name:"Frank Martin" age:32 birth:1965-12-24}

AXON puede representar una combinación de datos similares a XML y JSON.

AXÓN

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

o 

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)

Está disponible la biblioteca de Python. piaxon ahora.

Creo Plata clara es una muy buena alternativa.Incluso tienen una página de comparación. aquí y una lista de proyectos que lo use

Para almacenar datos similares a códigos, les (Loyc Expression Syntax) es una alternativa en ciernes.He notado que mucha gente usa XML para construcciones similares a códigos, como sistemas de compilación que admiten condicionales, invocaciones de comandos y, a veces, incluso bucles.Este tipo de cosas parecen 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, todavía no cuenta con un excelente soporte de herramientas;Actualmente, la única biblioteca LES es para C#.Actualmente, sólo se sabe que una aplicación utiliza LES: lllpg.Admite "atributos", pero son como atributos de C# o anotaciones de Java, no atributos XML.

En teoría, podría usar LES para datos o marcado, pero no existen 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 };

Si es alérgico a los corchetes angulares, entonces JSON, HDF (Plata clara), y OGDL Son los únicos que conozco de improviso.

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

YAML es un formato extremadamente completo y generalmente legible por humanos, pero su curación es la complejidad, 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, famoso por Github, dio un paso al frente para crear una alternativa sensata denominada TOML.Obtuvo una gran tracción de inmediato y tiene un excelente soporte de herramientas.Recomiendo encarecidamente a cualquiera que busque YAML que lo consulte:

https://github.com/mojombo/toml

AFAIK, JSON y YAML son exactamente equivalentes en términos de estructura de datos.YAML simplemente tiene menos corchetes, comillas y esas cosas.Entonces no veo cómo estás rechazando uno y manteniendo el otro.

Además, no veo cómo los corchetes angulares de XML son menos "legibles para humanos" que los corchetes, las llaves y las comillas de JSON.

Realmente existen muchas alternativas a XML, pero el principal problema con muchas de ellas parece ser que es posible que las bibliotecas no estén disponibles para todos los idiomas elegidos y que su implementación sea relativamente laboriosa.

Analizar una estructura de árbol en sí puede no ser tan agradable, si se compara con pares clave-valor, p.tablas hash.Si una instancia de tabla hash cumple con el requisito de que todas sus claves sean cadenas y todos sus valores sean cadenas, entonces es relativamente sencillo implementar hashtable2string() y string2hashtable().

He estado usando la serialización de tablas hash en AJAX entre PHP y JavaScript y el formato que he desarrollado se llama ProgFTE (Programmer Friendly text Exchange) y se describe en:

http://martin.softf1.com/g/n//a2/doc/progfte/index.html

Se puede encontrar una versión Ruby de la implementación ProgFTE como parte de la biblioteca Kibuvits Ruby:http://rubyforge.org/projects/kibuvits/

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top