studio - ¿Cuáles son los buenos formatos de datos alternativos para XML?
programacion android pdf 2018 (25)
No descartaría texto sin formato, como CSV o delimitado por tabuladores.
Realmente estoy buscando alternativas que tengan una estructura definida y soporte de biblioteca (multiplataforma, lenguaje múltiple). Estoy interesado en ver diferentes diseños y sus pros y contras. Me gusta la idea de los formatos que pueden tener un formato de texto y "binario" (compacto, "compilado", E / S rápida, tamaño más pequeño). La ventaja de tener bibliotecas es que realizan el análisis y tal vez la manipulación / validación de datos adicionales para usted.
A pesar de haber dicho eso, definitivamente hay un uso para formatos simples como .ini, .plist y CSV, etc. No siempre debe usar un martillo para romper una nuez.
XML, concedido, es muy útil, pero puede ser muy detallado. ¿Qué alternativas existen y están especializadas para un propósito particular? El soporte de la biblioteca para interrogar los contenidos fácilmente es un gran punto a favor.
¡Herejía! XML es el rey de los datos. ¡Di no a los usurpadores, fuera con sus cabezas! ¡Larga vida a XML!
Pero en serio, si solo necesitas datos, utiliza Json, para obtener soporte y elegancia, pero si necesitas formateo, consultas como xpath, metadatos adicionales, etc. ... Sigue con XML
Nota: Utilizo Xml para la generación de código de generación de sistemas de configuración y tareas similares, pero Json para Rpc, Sql para consultas y persistencia, y finalmente Yaml aquí y allá para el registro y tareas rápidas, en otras palabras, elija el formato adecuado para la necesidad.
¡No te olvides de YAML !
JSON parece tener un mejor soporte sin embargo. Por ejemplo, la biblioteca Prototype JS tiene excelentes funciones integradas de JSON.
¿Pero a qué precio?
Estoy totalmente de acuerdo con JSON en muchas situaciones, especialmente cuando el peso o el trabajo del cliente son una preocupación, pero alejarse de XML pierde legibilidad (tan importante en esos archivos de configuración) y el poder de las soluciones de problemas del mañana como XSLT y XPath. Esté realmente seguro de por qué y cuándo se va: es un estándar de facto por una razón.
(a un lado: mi hábito es usar XML internamente, y transformar eso a JSON donde ese es el resultado deseado)
¿Qué quieres hacer con los datos? ¿Guárdalo? Pásalo? Mostrarlo? Estas preguntas deberían impulsar su búsqueda de una tecnología apropiada. Simplemente preguntar cómo debe formatear sus datos es como preguntar en qué idioma debe programar, sin especificar lo que desea lograr.
Para la mayoría de las tareas de datos, el Dr. Codd tiene la cura: http://en.wikipedia.org/wiki/Edgar_F._Codd . Las bases de datos deberían poder hacer casi cualquier cosa que tengas en mente.
Si lo estás pasando, yo abogo por texto sin formato. Cuando mueves tu propio formato binario, tus datos desaparecen cuando tu analizador desaparece.
Con texto simple, la pregunta más profunda es dónde colocar los metadatos. Debe ser externo al archivo de datos, o interno ("autodescriptivo").
Por ejemplo, XML es texto plano, pero también lo es el código fuente. Con un archivo fuente, hay una especificación que entra en gran detalle en cuanto a la sintaxis y la semántica, mientras que XML se supone que es autodescriptivo. El problema es que no lo es. Además, evolucionó al salir de la presentación y el marcado del documento, pero ahora se está abusando de todo tipo de serialización, transferencia y almacenamiento de datos.
Acabo de terminar mi desarrollo en un formato de serialización que se puede aplicar para almacenar y transferir datos estructurados por árbol. El aspecto más importante de mi trabajo es que la técnica provista reduce la sobrecarga tanto para la serialización como para la deserialización. Intenté también mantener la implementación lo más fácil posible para que no sea un problema implementarla usted mismo en un día. Si está interesado puede ir a http://issuu.com/daniilm/docs/trifle donde coloqué mi especificación. Todo gratis y con muchos diagramas útiles.
Cualquier cosa que te guste, siempre que no sea ASN.1
El artículo de Jeff sobre The Angle Bracket Tax resume una serie de alternativas (bueno, principalmente YAML), y me llevó al artículo de la wiki sobre los lenguajes de marcado ligeros .
Actualización: aunque YAML es una posible "alternativa al XML" para algunas aplicaciones, las dos no son, como pensé primero, isomorfas.
De hecho, "no es lenguaje de marcado".
Además, YAML no es tan "liviano" como parece. Para los documentos que se pueden representar en XML simple (como el ejemplo de Jeff), YAML es claramente menos detallado. Pero YAML ofrece muchas otras estructuras especializadas, alistando muchos más personajes y secuencias que las reservadas por XML.
En pocas palabras, si busca XML sin paréntesis angulares, YAML no lo es.
En aras de la exhaustividad, mencionaré Edifact, para el cual escribí una interfaz hace mucho tiempo.
JSON se puede usar de muchas maneras, pero es particularmente adecuado para usar con las tablas de MySQL que encuentro. Funciona muy bien con Android también (biblioteca GSON o JSON). Más allá de eso, es efectivo para transmitir pequeños bits de datos individualmente o como matrices.
Las expresiones S funcionan muy bien si no necesita aplicar atributos a los elementos. Otra alternativa es YAML.
Mi trabajo con XML es casi exclusivamente con XML centrado en documentos, que debe modelar largas secuencias de estructuras anidadas arbitrariamente. Todavía no he usado JSON, pero mi impresión es que es engorroso de usar con datos similares a documentos, pero bien adaptado e incluso elegante para usar con datos de registro. Considere la forma de sus datos al tomar su decisión.
No descartaría texto sin formato, como CSV o delimitado por tabuladores.
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] // an "attribute"
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 .
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 };
Parece que hay un montón de soporte multiplataforma para JSON .
Podrías probar los protobufs de google. Es mucho más rápido que XML. Hay bibliotecas para ello en C, C ++, C #, Java y Python (hay versiones alfa para ruby y perl). Pero es binario.
Por el solo hecho de mencionar ... eche un vistazo a mi propuesta:
Es muy simple y no se overloadad con variedad de símbolos especiales, simplemente {} y "" básicamente.
Admite comentarios de estilo C ++.
Hay bibliotecas C ++, C # y Java.
Ejemplo:
"String object"
AnotherStringObject
"String with children"{
"child 1"
Child2
"child three"{
SubChild1
"Subchild two"
Property1 {Value1}
"Property two" {"Value 2"}
//comment
/* multi-line
comment */
"multi-line
string"
"Escape sequences /" /n /r /t //"
}
}
Si alguien busca una alternativa menos detallada a XML, que es más o menos isomorfa a XML, entonces está AXON . Para explicar, considere ejemplos de representaciones equivalentes tanto en XML como en AXON. También hay python de biblioteca piaxon que admite el formato AXON.
XML
<person>
<name>Alex</name>
<age>34</age>
<email>[email protected]</email>
</person>
AXON
person {
name {"Alex"}
age {34}
email {"[email protected]"}}
XML
<memo date="2008-02-14">
<from>
<name>The Whole World</name><email>[email protected]</email>
</from>
<to>
<name>Dawg</name><email>[email protected]</email>
</to>
<message>
Dear sir, you won the internet. http://is.gd/fh0
</message>
</memo>
AXON
memo {
date:2008-02-14
from {
name{"The Whole World"} email{"[email protected]"}}
to {
name{"Dawg"} email{"[email protected]"}}
message {"Dear sir, you won the internet. http://is.gd/fh0"}
}
XML
<club>
<players>
<player id="kramnik"
name="Vladimir Kramnik"
rating="2700"
status="GM" />
<player id="fritz"
name="Deep Fritz"
rating="2700"
status="Computer" />
<player id="mertz"
name="David Mertz"
rating="1400"
status="Amateur" />
</players>
<matches>
<match>
<Date>2002-10-04</Date>
<White refid="fritz" />
<Black refid="kramnik" />
<Result>Draw</Result>
</match>
<match>
<Date>2002-10-06</Date>
<White refid="kramnik" />
<Black refid="fritz" />
<Result>White</Result>
</match>
</matches>
</club>
AXON
club {
players {
player {
id:"kramnik"
name:"Vladimir Kramnik"
rating:2700
status:"GM"}
player {
id:"fritz"
name:"Deep Fritz"
rating:2700
status:"Computer"}
player {
id:"mertz"
name:"David Mertz"
rating:1400
status:"Amateur"}}
matches {
match {
Date{2002-10-04}
White{refid:"fritz"}
Black{refid:"kramnik"}
Result{"Draw"}}
match {
Date{2002-10-06}
White{refid:"kramnik"}
Black{refid:"fritz"}
Result{"White"}}}}
Si está preguntando desde la perspectiva de una DSL, Guile Scheme podría ayudar, como ya se sugirió con las expresiones S.
Personalmente también uso JSON para transacciones AJAX.
XML está bien para el marcado de texto, pero para la serialización de estructuras generales es una opción bastante mala, donde JSON es mucho más adecuado.
XML se utiliza a menudo para la configuración, y en este caso hay otros formatos de almacenamiento simples que se utilizan a menudo (menos orientados a documentos):
Hay varias maneras de leer y escribir, según la plataforma y el idioma.
El lenguaje declarativo simple es una buena alternativa al XML para tareas comunes como la serialización y la configuración. Proporciona una biblioteca de analizador C # y Java. Creo que se destaca al especificar todo tipo de metadatos sin la verbosidad de XML.
HDF5 es un formato de datos muy compacto con algunas características que son similares a xml. Las bibliotecas .net dejan mucho que desear, pero el formato escala muy bien tanto en términos de tamaño como de rendimiento.
TOML es la nueva gran cosa. Tiene la bondad de YAML sin las grandes especificaciones. Extiende un formato de archivo de configuración común y familiar. Es directamente análogo a (y traducible a) JSON. Tiene soporte en todos los grandes idiomas. Creado por el cofundador / presidente de Github Tom y nombrado narcisísticamente. Es impresionante. ¡Dale un tiro!
Muestra TOML:
# This is a TOML document. Boom.
title = "TOML Example"
[owner]
name = "Tom Preston-Werner"
organization = "GitHub"
bio = "GitHub Cofounder & CEO/nLikes tater tots and beer."
dob = 1979-05-27T07:32:00Z # First class dates? Why not?
[database]
server = "192.168.1.1"
ports = [ 8001, 8001, 8002 ]
connection_max = 5000
enabled = true
[servers]
# You can indent as you please. Tabs or spaces. TOML don''t care.
[servers.alpha]
ip = "10.0.0.1"
dc = "eqdc10"
[servers.beta]
ip = "10.0.0.2"
dc = "eqdc10"
[clients]
data = [ ["gamma", "delta"], [1, 2] ]
# Line breaks are OK when inside arrays
hosts = [
"alpha",
"omega"
]
JSON es válido YAML que podría ser muy útil. ¡Dos por uno!