Si XML es tan malo ... ¿por qué tanta gente lo usa? [cerrado]

37

Entiendo el propósito de XML, pero siempre escucho que la gente se queja de lo malo que es. Realmente no entiendo ¿qué tiene de malo? Por lo general, escucho los términos "hinchado" y "lento".

Pero supongo que como programadores, ¿para qué lo usas principalmente? ¿Y realmente lo considera "malo" ... porque si lo es, mucha gente lo usa para transportar datos ...

programming-practices xml
fuente
1
Tu respuesta está en la pregunta. La gente todavía lo usa porque la gente solía usarlo, y las opciones son (1) reescribir todo el código que lo usó antes de JSON y YAML, o (2) absorberlo y hacer lo estúpido. Mucha gente todavía perpetúa los ciclos de violencia también. Eso no prueba el valor inherente de la práctica.
Parthian Shot
55
Pruebe JSON para un documento real (página de manual, Knuth, Hamlet, etc.). Entonces comprenderá por qué XML es esencial. Este es un espacio donde JSON apesta (adelante, prueba). Usar uno en el espacio de diseño del otro es cuestionable. Los problemas de usar XML en el espacio de JSON son principalmente verbosidad y velocidad, mientras que los problemas de usar JSON en el espacio de XML tienden a involucrar portabilidad (intente interoperar con un amigo que hizo un libro en JSON, pero a su manera), integridad y problemas de interpretación que requieren mucho esfuerzo humano para solucionarlos. Use la herramienta adecuada para su trabajo.
TextGeek
XML solo es malo porque muchas personas abusan de él porque las cosas no fueron diseñadas para eso. Si no necesita que sus datos sean fácilmente extensibles (es decir, el esquema es utilizado por múltiples partes que necesitan interoperar, en lugar de dictarlo centralmente por una parte autorizada), y si sus datos no son un documento (es decir, si DOM lo haría ha habido una mala abstracción de sus datos), entonces XML no es adecuado para esas aplicaciones. Sin embargo, cuando el dominio de su problema corresponde a para lo que está diseñado XML, nada más coincide con XML. JSON, YAML, etc. no son adecuados para el espacio para el que XML está realmente diseñado.
Mentira Ryan

Respuestas:

90

Xml es ideal para lo que fue diseñado: un protocolo de transferencia de datos legible por humanos, neutral en la plataforma, con algunas capacidades para imponer la validación de datos a niveles bajos. Dudo que alguien que use Xml de esta manera tenga una queja real. ¿Es el formato de cable más sucinto? No. Pero hay peores opciones. ¿Es tan rápido como leer su formato binario personalizado? No. Pero sus socios comerciales pueden leerlo en cualquier pila que estén usando.

El problema, sin embargo, es que los humanos, especialmente la raza conocida como arquitectos empresariales, son malvados y toman cosas buenas y las hacen malas. En el caso de Xml, la primera parte de este siglo vio a Xml como el martillo universal para cada problema de TI. Espolvorea un pequeño diseño por comité y terminas con algunas monstruosidades horribles como SOAP y oXML . Ninguno de los dos debe ser deseado para los enemigos, sin importar amigos o colegas.

Wyatt Barnett
fuente
15
+1: cualquiera que haya tenido que lidiar con EDI solo desea que se haya inventado XML antes de que ocurriera ese desastre.
Scott Whitlock
12
+1 coincide con mis pensamientos casi exactamente. Solo agregaría eso para almacenar datos simples y simples, incluso si es jerárquico (pero no demasiado profundo, eso no combina bien con nada ), hay ciertos formatos que funcionan igual de bien, especialmente JSON y YAML. Esto último es impresionante en lo que respecta a la legibilidad humana.
11
Parafraseando a jwz: "Hay un cierto tipo de programador que analizará cualquier problema y dirá: 'Lo sé, usaré XML'. Ahora tiene dos problemas ".
Adam Crossland
13
Por favor, dime que oXML fue una broma, como Brainfuck o Whitespace o LOLCODE.
dsimcha
99
@Shamim Hafiz, SOAP es definitivamente una de las peores monstruosidades jamás criadas por la humanidad.
SK-logic
24

XML es solo una herramienta que viene en muchos sabores y usos. XML sobresale en algunas cosas y apesta en otras. Creo que uno de los problemas es que la gente ha visto XML "empresarial" que es innecesariamente complejo con espacios de nombres y basura esparcidos (¿SOAP, alguien?). El truco para diseñar formatos XML para humanos es agregar un significado real a los datos sin hacerlos abrumadores de leer.

Una de las cosas con las que la gente tiene problemas es que el XML a veces se ahoga en algún carácter o en algún soporte faltante. Sin embargo, hay tanto una ventaja como una desventaja incluso en eso. Lo bueno es que no tienes ambigüedad como la que tienes con HTML, donde diferentes casos de sintaxis semi-inválida se pueden interpretar de manera diferente.

La desventaja es que es un poco más difícil de autor y más difícil de aprender. Estoy de acuerdo en que se debe argumentar que la web no se habría vuelto tan grande tan rápido si HTML fuera tan estricto como XML, pero también argumentaría que nos alegraría si lo hiciera hoy. :)

Además, no lo use para todo solo porque pueda, tenga el sentido y el criterio para aplicarlo adecuadamente. Si todo lo que tiene es XML, tiende a ser siempre una transformación XSLT lejos de lo que desea. :)

Yo diría que el formato solo importa cuando los humanos necesitan interactuar con él. Si está escribiendo un programa que serializa algo y lo envía a un lugar donde será consumido por otro de sus programas, ¿a quién le importa cómo se vea siempre que sea lo más eficiente posible? Use un formato binario o conejitos y unicornios para todo lo que me importa.

Pros de XML

  • Cubre muchos casos extremos que YAML y JSON no
  • Existen excelentes herramientas para analizar y validar XML en una variedad de plataformas e idiomas diferentes.
  • XML se puede transformar fácil y poderosamente en otro formato (a través de cosas como XSLT)
  • Los documentos XML razonables son simples para que los humanos los lean y editen; no me digas que JSON es más fácil, no lo es :)
  • XML se describe a sí mismo hasta cierto punto, es decir, contiene directamente información sobre su estructura y significado (en contraste con la mayoría de los formatos binarios)
  • Maneja la codificación
  • Agnóstico de espacios en blanco, lo que facilita el uso multiplataforma
  • Se rompe si no está bien formado (garantiza que los datos sean estructuralmente correctos)
  • No es SGML

Contras

  • Verboso
  • No es tan rápido analizar como binario
  • Se rompe si no está bien formado (bloquea su aplicación)

Buenos usos

  • Archivos de configuración
  • Formatos de intercambio de datos
  • Formatos de archivo resistentes a la versión
  • Almacenar documentos en bases de datos

No tan buenos usos

  • Formatos de transferencia de datos
  • Serializar objetos
  • Almacenar datos relacionales en bases de datos
  • Formato de archivo para escenarios de E / S de alto rendimiento
Homde
fuente
13
Dudo que los "archivos de configuración" estén bajo "buenos usos". No son datos, sino instrucciones.
daknøk
3
Estoy con @ daknøk aquí: no puedo contar las veces que tuve que pasar una gran cantidad de tiempo descubriendo un error de configuración en un archivo XML de cientos de líneas que especifica la inyección de dependencia, que se basó en un pequeño error tipográfico en Un atributo XML.
Gjallar
3
Si los datos incorrectos bloquean una aplicación, ¿son los datos los que tienen un problema?
James Snell
44
Cualquier formato de archivo que esté malformado / dañado tiene el potencial de bloquear el software dañado. Entonces XML no es el culpable aquí ... solo su aplicación. De lo contrario, buena publicación.
Thomas Eding
3
¿Podría ampliar en "Cubre muchos casos extremos que YAML y JSON no".
Trevor Hickey
14

Jeff Atwood tiene una publicación de blog bastante buena en XML: The Angle Bracket Tax sobre esto si desea que una fuente hable de ello.

Los usos más comunes que tengo para ello son:

  • Servicios hablando entre ellos. Por ejemplo, un sitio web que utiliza un sistema de gestión de contenido debe enviar algunos datos a un sistema de gestión de relaciones con el cliente y esto se hace con XML.

  • Almacenamiento de configuración. Web.config y app.config son ejemplos comunes, pero los scripts nAnt también pueden usar algunos XML para ellos.

No creo que sea óptimo, pero eso solo no me hace mal.

JB King
fuente
11

Dos razones:

  1. Hay muchísimos malos programadores por ahí. XML puede ser malo, pero también es simple (al menos en la superficie) y hace que sea muy fácil escribir software malo. Sorta como VB.
  2. Muchas de las personas que toman estas decisiones no son programadores, sino tipos de negocios que solo han escuchado que "todos usan XML" y, por lo tanto, deciden que quieren que su producto también use XML.
Mason Wheeler
fuente
Qué puntos tan absurdos y totalmente inútiles. 1) XML está lejos de ser malo y no tiene absolutamente nada que ver con la calidad del software que la gente escribe, ya sea que lo elijan o no, he visto bastante buenos programadores de VB, lo que implica que si usas VB realmente escribes que el software es malo simplemente tonto porque hay una desconexión completa entre cómo escribes el software y con lo que usas para escribirlo. 2) Otra falsa suposición, elegir XML es excelente y la mayoría de las personas que lo eligen para bien o para mal son ciertamente programadores. XML no es una bala de plata, pero es bueno para ciertas cosas.
Eyal Solnik
2
@EyalSolnik: Algunas personas, cuando se les presenta un problema, piensan "Lo sé, usaré XML".<Problem:Worsening> <Problem:TimeDescription>Now</Problem:TimeDescription> <Problem:Posessive>they have</Problem:Posessive> <Problem:Quantity>many, many</Problem:Quantity> <Problem:WorseningDescription>more problems</Problem:WorseningDescription> </ProblemWorsening>
Mason Wheeler
3
El hecho de que las personas abusen de algo no significa que la tecnología en sí sea mala, puedes ver el mismo síndrome en muchos lugares.
Eyal Solnik
8

Por lo general, escucho los términos "hinchado" y "lento".

No es la sintaxis más compacta, pero es claramente la más expresiva. ¿Legible por humanos? depende de cómo diseñas tu idioma. La mayoría de las personas no diseñan un lenguaje para XML, solo serializan objetos como XML.

... ¿por qué tanta gente lo usa?

Es omnipresente. Puede consultar una base de datos XML con XQuery, transformar los resultados con XSLT como XHTML o Atom, obtener Atom u otro formato XML de otros servicios web, obtener XML de los usuarios que usan XForms, validarlo con XMLSchema, Relax NG o Schematron, procesarlo con XProc, guárdelo de nuevo en la base de datos con XQuery Update. Todas estas herramientas entienden XML, por lo que no hay necesidad de mapear entre diferentes representaciones.

XML no es una tecnología de serialización, es un conjunto de información de propósito general.

Max Toro
fuente
... y nos preguntamos durante años por qué para Dios se ha creado SOAP sobre XML.
JensG
6

Aquí, lo usamos para el intercambio de datos entre diferentes sistemas realizados por diferentes proveedores con diferentes representaciones internas. Creamos un sistema de transformación / intercambio XML para transportar los datos de un lado a otro. Funciona bien para eso.

XML no es inherentemente malo, pero reconozco que diseñar una solución "buena" usando XML no es trivial.

FrustratedWithFormsDesigner
fuente
5

"La esencia de XML es esta: el problema que resuelve no es difícil y no resuelve bien el problema". - Phil Wadler, POPL 2003

Mi opinión personal es que mientras no te importe la validación, los esquemas, los XSLT y el resto de cosas feas y mantengas pequeño el tamaño de los archivos (de lo contrario, el análisis se vuelve lento) puedes encontrar algunos buenos usos de XML (un ejemplo es para configurar su aplicación en lugar de usar archivos INI).

sakisk
fuente
4

En mi experiencia, la mayoría de las personas se quejan de la forma en que se usa, no de la tecnología en sí.

Los bits inflados y lentos de los que la gente se queja generalmente son las bibliotecas / métodos que se utilizan para obtener información de ellos.

Lo uso para almacenar pequeñas cantidades de información estructurada que quiero almacenar en el disco (sin una base de datos o serialización binaria), o pasar a otra aplicación (que esencialmente describe SOAP también).

Steven Evers
fuente
2

Es bueno porque:

Es una "interfaz" estándar que pueden comunicarse múltiples sistemas heterogéneos para comunicarse. Y es "humano" legible (más o menos, intente mirar a 5 MB XML)

Es malo porque:

Su tamaño hinchado, más grande = más ancho de banda = más $$

Hay otras razones, cada uno tiene una queja diferente ...

Noche oscura
fuente
44
@Darknight: desafío a los humanos legibles lanzándoles entidades Xml ... (molestia personal)
Matthieu M.
1
No creo que XML esté inherentemente hinchado, pero las implementaciones de él sí lo están. Encuentro que XML-RPC es particularmente atroz con la hinchazón innecesaria.
HorusKol
3
@HorusKol: <advanceAcceptanceIndicator>Y</advanceAcceptanceIndicator>La relación datos / marcado es muy baja ... Yo llamo a esto "hinchado". JSON, por ejemplo, sería sólo como medio hinchado: advanceAcceptanceIndicator: "Y". También existe el hecho de que el texto entre etiquetas es válido, por lo que al leer Xml, debe decidir qué hacer con este cruft \n\t\t\t, y la solución generalmente es ignorarlo, porque para empezar nunca estuvo realmente interesado en esto.
Matthieu M.
1
@HorusKol: Lo haría, pero nunca dije que fuera un valor booleano, simplemente es un carácter único :) El uso del atributo aquí ( value?) Probablemente también sea superior, porque las personas podrían verse tentadas a insertar espacios en blanco entre dos Etiquetas
Matthieu M.
1
"Es hinchado, de mayor tamaño = más ancho de banda = más $$" Supongo que la compresión aún no se ha inventado donde estás.
Andy
2

Como para cualquier otra tecnología: hay muchas herramientas y bibliotecas disponibles.

No me gusta el XML, especialmente porque es funky, cuando la gente dice que es legible para el ser humano, bromean, creo, o nunca han leído realmente un xml cuando uno intenta incrustar xml en un atributo ... las entidades xml lo hacen realmente ilegible. Además, es sorprendente cuánto espacio se desperdicia debido a la etiqueta final redundante y la capacidad de mezclar texto libre y datos ...

Pero:

  • Se puede especificar Xml (xsd) y hay herramientas disponibles que verifican la conformidad de los datos Xml
  • muchas herramientas (editores de texto y similares) son compatibles con Xml
  • muchas bibliotecas (en casi todos los lenguajes de programación) admiten Xml

También tiene la ventaja de la precedencia, la mayoría de las veces. Cuando ya está proporcionando servicios web en Xml, y uno solicita un nuevo servicio ... probablemente se hará en Xml porque eso es lo que sabe.

Matthieu M.
fuente
55
XML es más legible que los datos binarios o delimitados por posición o coma.
FrustratedWithFormsDesigner
Solo para un usuario ingenuo. Si tengo que escanear visualmente un par de cientos de registros en busca de uno al que le faltan algunos datos, prefiero buscar algunas columnas en blanco en un bloque de registros de longitud fija en lugar de pasar por un conjunto de elementos y atributos en busca de una etiqueta vacía.
TMN
1
@FrustratedWithFormsDesigner: realmente depende de los datos disponibles. Xml incorpora la naturaleza de la información cerca de la información adecuada. Si observa los lenguajes de programación funcionales, verá cosas como (Haskell): data Person = Person { surname :: String, firstName :: String, age :: Int }si luego veo que Person "Doe" "John" 42también es legible y evita muchas desviaciones, sin embargo, está más cerca delimitado por comas.
Matthieu M.
1
Ok, su ejemplo fue más fácil de leer sin el marcado, pero se pueden hacer ejemplos triviales (diría menos de 8 o 9 elementos de datos) para admitir todos los formularios (excepto tal vez binarios). Las fuentes de datos del mainframe se originan como cadenas delimitadas por posición (y la mayoría son solo códigos numéricos), y son mucho más fáciles de leer, depurar y administrar después de transformarse a XML. Como dijiste, puede depender ...
FrustratedWithFormsDesigner
@FrustratedWithFormsDesigner: Sí, ese es exactamente mi punto :) Depende, pero debido a que hay un ecosistema tan rico para XML y porque es más fácil mantener solo un conjunto de herramientas / bibliotecas, la gente generalmente usa XML para todo. Personalmente, estoy a favor de JSon sobre XML, pero una vez más sin sangría, es desordenado: p
Matthieu M.
-1

XML es una mala elección para archivos que deben ser mantenidos por humanos. No hay separación visual entre el marcado y el contenido, lo que dificulta la lectura. Es tedioso escribir correctamente sin un editor especial. Cualquier error en un documento XML es fatal; un documento XML no puede procesarse parcialmente. Cuando un archivo XML no es válido, el mensaje de error resultante a menudo es inútil.

Para cualquier archivo que deba ser mantenido por un humano, preferiría usar JSON, YAML o código fuente en algún lenguaje interpretado (Python, Ruby, Groovy, etc.). Hemos descubierto que una excelente manera de crear una configuración XML para el código heredado es usar Groovy MarkupBuilder. Otra buena opción es crear un lenguaje específico de dominio; Esto es bastante fácil de hacer con Ruby, Groovy y muchos otros idiomas.

Kevin Cline
fuente
8
Creo que te estás perdiendo el punto de XML, el marcado es contenido. El propósito de XML es describir el significado de sus datos. Por ejemplo, si tiene un número de teléfono, etiquetarlo como un número de teléfono fijo o número móvil agrega un contexto que otros podrían usar. O agregar una etiqueta de teléfono alrededor del texto para el caso (podría hacer que ese número sea invocable en un teléfono móvil). En cuanto a sus otros puntos, no estoy de acuerdo. La creación de documentos xml suele ser bastante sencilla. Los mensajes de error siempre están relacionados con la buena forma y tomaré la edición de XML a mano sobre JSON cualquier día
Homde
@konrad su ejemplo de teléfono sería válido para HTML.
Florian F
"Cualquier error en un documento XML es fatal; un documento XML no puede procesarse parcialmente". Sí, eso es un gran par al punto de XML.
Andy
@Andy Es bastante inútil si el XML fue escrito por el humano y la aplicación simplemente dice "¡mal!". Un editor humano necesita saber la línea donde se detectó el error.
Kevin Cline
Cualquier cantidad de herramientas le dice exactamente en qué línea y, a menudo, en qué carácter se detecta el error. Herramientas XML en NotePad ++ por ejemplo. .Net también le dirá exactamente dónde está mal su archivo .config. Si está hablando de una API, uno de los beneficios de XML es que el desarrollador de la API también puede proporcionar un XSD, que además de garantizar una sintaxis XML válida también puede decirle si tiene elementos que no pertenecen, si es necesario solo ser uno de ese elemento, etc. Json manuscrita es mucho más fácil de fastidiar.
Andy
-2

El análisis es relativamente fácil y al mismo tiempo es legible para los humanos.

Y algunos analizadores agradables (por ejemplo, Xerces {c ++}) están fácilmente disponibles.

Simon
fuente
2
Bueno, es fácil siempre que los documentos sean pequeños. Si tiene que analizar documentos demasiado grandes para que quepan razonablemente en la memoria, entonces las cosas se ponen sombrías.
TMN
Yo cuestionaría la parte de legibilidad humana. Simplemente toma demasiado esfuerzo leer XML sobre leer un JSON equivalente.
cmaster