Antes de que XML se convirtiera en un estándar y presentara todas sus deficiencias, ¿qué hizo que XML fuera tan popular?

standards popularity (23)

Lenguajes de definición de esquema: puede describir el formato esperado del XML
Es un estándar :) - definitivamente es mejor que todos usando sus propios formatos personalizados

CSV es legible por humanos, pero eso es realmente lo único bueno de esto: es tan inflexible y no hay significados asignados a los valores. Si comenzara a diseñar un sistema ahora definitivamente usaría YAML , está menos hinchado y definitivamente está ganando impulso.

Sí XML es legible por humanos, pero también lo es el texto delimitado por comas y los archivos de propiedades.

XML está hinchado, es difícil de analizar, difícil de modificar en el código, además de una tonelada de otros problemas con los que puedo pensar.

Mis preguntas son ¿cuáles son las cualidades más atractivas de XML que la han hecho tan popular?

¿Qué tal el hecho de que sea compatible con un lenguaje de consulta estandarizado, XPath? Eso es bastante útil para mí.

¿Recuerdas los días antes de que XML se hiciera popular? Los datos simplemente no eran intercambiables: un programa tomaría archivos .csv, los siguientes .xls y los siguientes archivos con formato EBSIDIC. XML tiene sus debilidades, pero está estructurado, lo que lo hace procesable y transformable.

Como usted señala, los archivos CSV son bastante portátiles. Sin embargo, no tiene sentido para ellos. ¿Qué significa la columna (14) para mí? ¿A diferencia de <customer id = "14" />?

Algunas cualidades inherentes de XML que lo hacen tan popular y útil:

XML representa un árbol, y las estructuras de árbol son un patrón muy común en la programación. Este es un salto evolutivo de representaciones basadas en registros como CSV, hecho posible por el bajo poder de computación y ancho de banda de hoy en día.
XML logra un buen equilibrio entre factores humanos (es texto plano, y bastante legible) y aspectos prácticos de la informática (concisión, facilidad de análisis, expresividad, extensibilidad, etc.).

Directamente de la boca del caballo , los objetivos de diseño de XML fueron:

XML se podrá usar directamente en Internet.
XML debe admitir una amplia variedad de aplicaciones.
XML debe ser compatible con SGML.
Será fácil escribir programas que procesen documentos XML.
El número de funciones opcionales en XML se debe mantener al mínimo absoluto, idealmente cero.
Los documentos XML deben ser legibles por los humanos y razonablemente claros.
El diseño XML debe prepararse rápidamente.
El diseño de XML debe ser formal y conciso.
Los documentos XML serán fáciles de crear.
La rigurosidad en el marcado XML es de mínima importancia.

La razón por la cual se hizo popular fue porque las personas necesitaban un estándar para un formato de intercambio de datos multiplataforma. XML puede estar un poco hinchado, pero es una forma muy simple de delimitar datos de texto y era compatible con la gran cantidad de sistemas SGML existentes.

Realmente no puede comparar XML con CSV porque CSV es una forma extremadamente limitada de representar datos. CSV no puede manejar nada fuera de una tabla básica de filas y columnas y no tiene noción de jerarquía.

XML no es tan difícil de analizar y, una vez que escribes o encuentras una utilidad XML decente, tampoco es difícil tratar con el código.

Eran los últimos años de la década de los 90 y el internet estaba muy caliente, pero las compañías tenían sistemas que no podían acercarse a Internet. Habían pasado innumerables horas lidiando con CORBA y planeaban utilizar Enterprise JavaBeans para que estos sistemas antiguos se comunicaran con sus sistemas más nuevos.

Luego viene SGML, que es el precursor de casi todos los lenguajes de marcado (me salteo GML). SGML ya se usaba para definir cómo definir HTML, pero HTML tenía etiquetas particulares que TENÍA que usarse para que Netscape muestre correctamente una página web determinada.

Pero, ¿y si tuviéramos otros datos que necesitaban explicarse? ¡Ah, ja!

Entonces, dado que XML está estructurado, y puede sentirse libre de definir esa estructura, naturalmente le permite construir interfaces (en un punto de vista que no sea de OO). En realidad, no hace nada que otros lenguajes de interfaz ya hacen, pero le dio a la gente la capacidad de diseñar sus propias definiciones.

Los lenguajes de interfaz como X12 y HL7 existían con seguridad, pero con XML las personas podían adaptarlo a sus sistemas individuales AIX o AS / 400.

Y con el predominio del lenguaje de etiquetas debido al HTML, fue natural que XML se pusiera a la vanguardia por su facilidad de uso.

Es estructurado

Es más fácil escribir un analizador para un dialecto XML que para un arbitrario debido a las herramientas que están disponibles.

El uso de un analizador DOM, por ejemplo, es mucho más simple que lexx y yacc, especialmente en Java, donde se popularizó.

La principal ventaja que otorga es una representación independiente del sistema de datos jerárquicos. Los archivos de texto y propiedades delimitados por comas son más apropiados en muchos lugares donde se usó XML, pero la capacidad de representar estructuras de datos complejas y tipos de datos, reconocimiento de conjuntos de caracteres y documentos de estándares permitió que se utilizara como un buen formato de intercambio entre aplicaciones.

Mi sugerencia de mejora menor para el lenguaje es cambiar la forma en que funcionan las etiquetas finales. Solo imagina cuánto ancho de banda y espacio de disco se guardarían si pudieras terminar una etiqueta con </> , como <my_tag>blah</> lugar de < my_tag>blah</my_tag> . No tiene permitido superponer etiquetas, por lo que no sé por qué la norma insiste en incluir más texto de lo necesario. De hecho, ¿por qué utilizar los soportes angulares en absoluto?

La fealdad de los corchetes angulares es un buen espectáculo de lo que podría haber sido: JSON. La notación de objetos JavaScript logra la mayoría de los objetivos de XML con mucho menos tipeo. Otra sintaxis alternativa que hace soportable XML es la sintaxis de Builder, tal como la usan Groovy y Ruby. Es mucho más natural y legible.

Tiene muchas ventajas y pocas deficiencias. El principal problema es el aumento del tamaño del archivo y el procesamiento más lento. Sin embargo, hay ventajas:

está estructurado, por lo que escribes un analizador solo una vez
admite datos con estructura anidada (jerarquías, árboles, etc.)
puede incrustar múltiples tipos de estructura de datos en un solo XML
puede describir el esquema (tipos de datos, etc.) con el lenguaje estándar (XSL ...)

Una de las principales ventajas que tiene sobre cosas como archivos CSV es que puede representar datos jerárquicos fácilmente. Para hacer esto, necesitas una estructura de árbol autodescriptiva como XML, o un formato predefinido como SWIFT o EDI (y si alguna vez has tratado con cualquiera de esos, entonces te darás cuenta de que XML es trivial para analizar en comparación).

Una de las razones por las que en realidad es bastante fácil de analizar es porque está "hinchado". Esas etiquetas finales significan que puedes unir con precisión el final de los elementos al comienzo y calcular cuándo el árbol se desequilibró. No puede hacer eso en las alternativas ''ligeras'' como JSON.

Otra razón por la que es fácil de analizar es porque tiene soporte completo para codificaciones Unicode desde el principio, por lo que no tiene que preocuparse por cuál es la página de códigos predeterminada en el sistema de destino, o cómo codificar caracteres de varios bytes, porque esa información está contenida en el documento.

Y no nos olvidemos de los otros artefactos que vinieron con él, como la descripción definida y el mecanismo de validación (XSD) y el poderoso y declarativo mecanismo de transformación (XSLT).

XML no es difícil de analizar, de hecho es bastante simple, dado el volumen de excelentes API disponibles para todos los idiomas bajo el sol.

XML en sí mismo no está inflado, puede ser tan conciso como sea necesario, pero depende de su esquema mantenerlo de esa manera.

XML maneja conjuntos de datos jerárquicos de una manera que el texto delimitado por comas nunca podría o debería.

XML es autodocumentado / descriptivo, y legible por humanos. ¿Por qué es un estándar? Bueno, antes que nada, porque puede estandarizarse. CSV no es (y no puede ser) un estándar porque hay una cantidad infinita de variación.

es compatible con muchos idiomas

Puede recibir un archivo xml y tener la oportunidad de comprender lo que significan los datos al leerlo sin necesidad de una especificación por separado de su formato de datos pre-xml.
Las herramientas se pueden usar para trabajar con xml genéricamente. Donde antes, si todos usaran diferentes formatos de archivo: separados por comas, binarios, etc. Tendría que escribir una herramienta personalizada.
Puede ampliarlo agregando una nueva etiqueta en el esquema con un valor predeterminado. Y si se hace correctamente, con xml que no rompa todo el código anterior que analiza el xml pero no conoce la etiqueta. Eso generalmente no es cierto con los formatos de propiedad.
Probablemente lo principal que lo hace popular es que se parece un poco al HTML, que mucha gente entendió anteriormente. Entonces se hizo popular, luego porque era popular se hizo más popular porque es bueno trabajar con un estándar que todos conocen.
Una cosa mala es que xml suele ser mucho más grande debido a todas las etiquetas y porque su texto se basa en que solía usarse. Pero, como las computadoras son más grandes ahora, a menudo podemos manejar eso y vale la pena cambiar el tamaño por tener mejores datos de autodescripción.
Puede salir del código / bibliotecas del estante que analizará / escribirá xml.

Algo que no he mencionado aún es que no solo está estructurado el XML, sino que la forma en que interactúan los atributos y los elementos crea una estructura algo inusual que los humanos aún pueden entender fácilmente.

Si compara un árbol XML con su vecino estructural más cercano, el gráfico acíclico dirigido, puede observar que el DAG típico solo lleva una ID y un valor en cada nodo. XML lleva esto también (gi / tag correspondiente con ID, y el texto del nodo correspondiente con el valor), pero cada nodo también puede transportar una cantidad arbitraria de metadatos adicionales: los elementos. Esto es muy parecido a tener una dimensión extra: si considera que el DAG se extiende horizontalmente en dos dimensiones con cada rama, el documento XML se extiende en tres dimensiones, plano y luego hacia abajo hasta un subárbol que contiene solo los atributos.

Esta es una curva opcional a la estructura. Haga una lista de atributos como cualquier lista de elementos secundarios y vuelva a un árbol bidimensional. Ignorelos por completo, y tiene un árbol de nodos / valores simplificado que puede representar más puramente la "forma" general de los datos contenidos. Pero la dimensión extra está ahí si necesita los metadatos.

Con una sangría decente, esto es algo que un ser humano puede captar con sólo mirar los datos brutos, haciendo que XML sea una herramienta de visualización en miniatura para una estructura potencialmente compleja, y tener una herramienta de visualización integrada en el intercambio de datos significa que los programadores Es más probable que los involucrados construyan una estructura que represente la forma en que los datos serán utilizados.

Comparado con algunos de los estándares anteriores, es un sueño. Intente escribir archivos HDF (formato de datos jerárquicos) o FITS. FITS se estandarizó antes de la invención de la unidad de disco: ¡tiene que preocuparse por rellenar el archivo en bloques!
Incluso CSV no es tan simple. Pregunta rápida, ¿cuál es el separador en un archivo CSV alemán?

Muchas de las quejas sobre XML provienen de personas que lo utilizan para transferir datos directamente entre máquinas donde los datos solo existen durante milisegundos. En muchas áreas, los datos tendrán que durar de 50 a 100 años y serán mucho más valiosos que la máquina en la que se ejecutó. Vale la pena pagar un impuesto de etiqueta de cierre a veces.

Es multiplataforma. Lo utilizamos para codificar el programa de control del robot y los datos que se ejecutan en C bajo VxWorks para su ejecución, pero nuestra programación fuera de línea se realiza en punto net. XML es fácilmente analizado por ambos.

La popularidad de XML se deriva de otros lenguajes de marcado. El HTML es con el que las personas están más familiarizadas, pero cada vez más vemos los lenguajes de "rebajas" como los utilizados por los wikis e incluso los formularios de .

HTML hizo un trabajo interesante, de formato de texto, pero fue insuficiente. Creció. La gente quería agregar etiquetas para todo. <BLINK> ¿Alguien? Diseños, estilos e incluso datos.

XML es el lenguaje de marcado extensible (duh, ¿verdad?), Diseñado para que cualquiera pueda crear sus propias etiquetas, y para que su etiqueta RECORD no interfiera con mi etiqueta RECORD, en caso de que tengan diferentes significados, y con sensibilidad a la problemas de codificación y coincidencia de etiquetas y escapes que HTML tiene.

Al principio, era popular entre personas que ya conocían HTML, y les gustó el concepto familiar de usar el marcado para organizar sus datos.

Las dos cosas principales que hicieron que XML sea ampliamente adoptado son "Legibilidad humana" y "Sun Microsystem". Eran (y todavía existen) otros formatos de intercambio de datos entre plataformas y en varios idiomas que son más flexibles, más fáciles de analizar y menos detallados que XML. Tal como ASN.1 .

Supongo que su popularidad se originó originalmente en el hecho de que resolvió los problemas correctos de una manera que no era demasiado mala para que los grandes jugadores ganaran su apoyo y obtuvieran así la adopción generalizada de la industria. En este punto, está bastante arraigado en el paisaje ya que hay tanto desarrollo de componentes invertidos en XML. HIPPA y otros esquemas y adaptadores XML EDI que se entregan con MS BizTalk Server (y BizTalk en sí mismo) son un gran ejemplo de la montaña que se ha ido construyendo gradualmente sobre XML.

Es un formato de texto que es una de sus principales ventajas. Todos los formatos binarios suelen ser mucho más pequeños, pero siempre se necesitan herramientas para "leerlos". Simplemente puede abrir y editar y modificar archivos XML a su gusto. Sin embargo, yo diría que aún es un formato inflado, pero bueno, puedes comprimirlo bastante bien ... si uno mira las especificaciones para los formatos XML de Windows Office, uno puede imaginar que es maravilloso estar aparentemente abierto ...

Saludos Friedrich

Otro beneficio de XML frente a los datos binarios es la resiliencia de error.

para datos binarios, si un solo bit sale mal, la información probablemente no se puede usar, con xml, como último recurso, aún puede abrirla y hacer correcciones ...

XML proporciona una forma muy sencilla de representar datos. El análisis es bastante fácil: es una gramática muy regular y se presta para un análisis de descenso recursivo directo. Esto facilita que los consumidores y productores de datos intercambien información sin tener que saber demasiado acerca de sus respectivas aplicaciones e internos.

Sin embargo, es una forma extremadamente ineficaz de representar datos y se presta a un abuso horrible. Un ejemplo de esto es una interfaz de objeto con la que trabajé que, en lugar de exportar constructores y propiedades para objetos particulares, me exigía que creara XML programáticamente y pasara el XML resultante al único constructor. Del mismo modo, XML no se presta bien a grandes conjuntos de datos que pueden requerir acceso aleatorio sin crear un sistema de catalogación añadido (es decir, si tengo un documento de mil páginas en XML, tendré que analizar casi todo el archivo para llegar a la página 999 , asumiendo que los datos de la página estén ordenados), mientras que sería mejor colocar los datos de la página real en un archivo o archivos separados y usar el XML para señalar el archivo correcto o la posición dentro de un archivo.