¿Podemos reemplazar XML con JSON por completo? [cerrado]

78

Estoy seguro de que muchos desarrolladores están familiarizados con XML y JSON , y los han usado a ambos. Por lo tanto, no tiene sentido explicar cuáles son y cuál es su propósito, incluso en breve.

Si intentamos mapear sus conceptos, podemos decir (corrígeme si me equivoco):

  1. Las etiquetas XML son equivalentes a JSON {}
  2. Los atributos XML son equivalentes a las propiedades JSON
  3. La colección de etiquetas XML es equivalente a JSON []

Lo único que se me ocurre, que no existe en JSON, son los espacios de nombres XML .

La pregunta es, considerando este mapeo, y considerando que JSON es altamente más ligero en este mapeo, ¿podemos ver un mundo en el futuro (o al menos pensar en un mundo teóricamente) sin XML, pero con JSON haciendo todo lo que XML hace? ¿Podemos usar JSON en todas partes donde se usa XML?

PD: Tenga en cuenta que he visto esta pregunta. Es algo completamente diferente de lo que estoy preguntando aquí. Por lo tanto, no mencione duplicados .

Saeed Neamati
fuente
14
Obviamente, podemos (y debemos) reemplazar todas esas cosas mal diseñadas sobreexpuestas con expresiones S. Mundo sin XML sería un lugar mucho mejor, pero desafortunadamente no es más que una ilusión.
SK-logic
19
Ugh Odio estas preguntas. Creo que este es realmente un caso para usar la herramienta adecuada para el trabajo, y no si uno puede reemplazar a otro por completo. Hay muy pocos absolutos en el mundo, incluso con las computadoras. No podía imaginar hacer ninguna de las cosas que hago con JSON, al menos donde están las tecnologías respectivas ahora.
Philip Regan
2
@Philip, esta no es una pregunta para demoler algo. Solo trata de ver qué le falta a JSON, para que podamos mejorarlo. :)
Saeed Neamati
44
Una discusión sobre las diferencias entre dos tecnologías para ver dónde se pueden hacer mejoras es muy diferente a preguntar si una puede reemplazarse por la otra. La primera es una revisión más académica que la segunda, que suena más antagónica por la frustración que cualquier otra cosa
Philip Regan el
12
Esto no es hipotético. JSON parece carecer de una característica que posee XML.
S.Lott

Respuestas:

153

Lo que le da a XML su poder y gran parte de su complejidad es el contenido mixto. Cosas como esta:

<p>A <b>fine</b> mess we're in!</p>

Ni siquiera intentes hacer eso en JSON, o manipularlo en lenguajes de programación convencionales. No fueron diseñados para el trabajo.

Este tipo de pregunta generalmente proviene de personas que olvidan que la M en XML significa marcado. Es una forma de tomar texto sin formato y agregar marcas para crear texto estructurado. También es bastante útil para datos anticuados, pero no es para eso para lo que fue diseñado ni para dónde residen sus puntos fuertes. Hay muchas formas de manejar datos simples, y JSON es una de ellas.

Michael Kay
fuente
33
+1: esta es la característica distintiva. Excelente punto
S.Lott
77
@ Michael, me acabas de enseñar algo valioso. Esta es una respuesta genial. +1.
Saeed Neamati
99
.... Hay 3 nodos indie de P, A el elemento B y el "desastre en el que estamos". Es una matriz, que simplemente puede explicar en JSON.
Incognito
55
@Rob No, pero estoy explicando que podría definir las cosas expresadas por HTML con mayor claridad, y quizás un análisis más rápido a través de JSON (ya que se requiere menos análisis del texto para encontrar los diferentes tipos de nodos). Si HTML fuera JSON-ML, podríamos tener más desarrolladores que realmente entiendan el DOM, los nodos de texto y los enlaces.
Incognito
55
@ByrneReese: sí, es XML y sí, es válido. Que también es HTML no viene al caso; de hecho, XHTML también es XML válido. :-)
Martijn
31

La principal diferencia, creo, está en el hecho de que XML está diseñado para explicarse por sí mismo con sus dtd y todo.

Con JSON, debe asumir muchas cosas sobre los datos que está recibiendo.

Maarten van Leunen
fuente
77
"XML está diseñado para explicarse por sí mismo". ¿Puede proporcionar un enlace o una referencia para esto? No lo veo en los estándares W3C para XML, y me pregunto de dónde viene esta noción. Parece una leyenda urbana más que un objetivo de diseño declarado.
S.Lott
66
@ S.Lott: Creo que lo que quiere decir con eso es la naturaleza de las etiquetas XML, en sí mismas, permite que el contenido etiquetado se explique por sí mismo, es decir, los DTD son opcionales, por lo que XML bien formado puede analizarse sin uno. Pero estoy de acuerdo con su opinión sobre el tema porque, técnicamente, JSON tiene la misma capacidad, por lo que no creo que la autoexplicación sea la principal diferencia (no estoy seguro de por qué esto sigue siendo votado), sino más bien Michael Kay está más en la marca.
Philip Regan
55
@ S.Lott estuvo de acuerdo. Debo decir que el JSON aquí json.org/example.html es más fácil de entender y está mejor documentado que el XML asociado debido a su falta de verbosidad.
Doug T.
44
@Michael Borgwardt: Sin un XSD completo (incluido algún tipo de soporte de ontología), los nombres de las etiquetas no me dicen nada. "significativo" es difícil de lograr en general. Eso no me deja claro qué se supone que significa "autoexplicarse" en la respuesta. Y no tengo evidencia de que incluso fuera un objetivo de diseño para XML.
S.Lott
44
@Philip Regan: Al igual que con el "código autoexplicativo", no parece ser una característica de XML. Si es solo un objetivo de implementación universal que se aplica a todos los lenguajes de software (código, acceso a datos, marcado, lo que sea), tal vez la gente no debería mencionarlo específicamente sobre XML.
S.Lott
21

Una traducción literal a JSON es a menudo menos sucinta y menos clara. Considerar:

<foo>
   <x:bar x:prop1="g">
      <quuz />
   </bar>
</foo>

La representación JSON más efectiva que he visto de esto:

{"localName":"foo",
 "children": // you need to have a special array to hold all children
 [
    {"localName": "bar",
     "namespace": "x"
        // once again, to ensure that there are no collisions,
        // attributes should be brought out into their own JSON structure 
        "attributes":[
            {"localName":"prop1",
             "namespace":"x",
             "value":"g"}
        ],
         "children":[
             {"name":"quux"}
         ]
     }
 ]}

Ahora, imagine eso para un archivo XML completo. No estoy diciendo que JSON no tenga su lugar, pero XML no debe descartarse.

cwallenpoole
fuente
8
Ahora considere SXML:(foo (x:bar (@ (x:prop1 "g")) (quuz)))
SK-logic
2
@ SK-Logic: Eso es genial para un ejemplo trivial, pero no podía imaginar hacer contenido mixto profundamente anidado, como un libro, con eso. Creo que SXML es tanto un ejercicio académico como cualquier otra cosa.
Philip Regan
3
@Philip Regan: ¿Cómo puede ser más difícil escribir un S-Exp que usar chevronitis, cuando se trata de una transformación trivial 1: 1 en una forma menos detallada?
maaartinus
@maartinus: Mi campo de especialización es la publicación de libros: los libros de texto de cualquier tipo son bestias profundas y complejas con una amplia gama de contenido que requiere una gestión explícita. DocBook y DITA son mucho más legibles que el ejemplo anterior.
Philip Regan
1
@Philip Regan, SXML es muy fácil de editar, a diferencia de XML. Y, por supuesto, es una opción mucho mejor para protocolos, no hace falta mencionar la superioridad de las herramientas disponibles.
SK-logic
14

JSON y XML son dos formas de formatear datos. Ambos son capaces de hacerlo perfectamente bien, ¿puede JSON hacer todo lo que hace XML? Si.

Pero ..... Una pregunta más relevante podría no ser qué puede hacer XML / JSON, sino qué puede hacer con XML / JSON.

Hay varias cosas que puede hacer con XML que no creo que pueda hacer con JSON, como traducir con XLST, buscar con XPath y validar con esquemas. Todo muy, muy útil.

Qwerky
fuente
55
Excepto para contenido mixto donde los datos contienen etiquetas. JSON no lo hace muy bien en absoluto.
S.Lott
11

Hay mucha funcionalidad con XSLT que puede no ser posible con JSON. Entonces, si no son funcionalmente equivalentes, no podrían reemplazarse entre sí.

StuperUser
fuente
3
Dicho esto, podría usar otro lenguaje para deserializar, manipular y serializar JSON, y XSLT no es XML, por lo que este punto es realmente discutible.
StuperUser
3
XSLT es XML - vea el esquema aquí
treecoder
Gracias @greengit, solo he tenido una breve exposición, actualicé la respuesta.
StuperUser
2
@StuperUser: ¿Cómo podría ser "imposible" con JSON? Es solo una transformación, tal vez las herramientas aún faltan. ¿O el problema está relacionado con la falta de atributos en JSON?
maaartinus
1
@StuperUser: XSLT es un lenguaje (subconjunto de XML) para el cual algunos intérpretes fueron escritos en al menos otro lenguaje (probablemente en C, Java, ...). Lo mismo podría hacerse para JSON (definir algunos JSON-T, escribir el intérprete), ¿no?
maaartinus
8

El hecho es que tendremos que vivir con ambos durante mucho tiempo, y ser un fanático de JSON es "considerado dañino".

Scott C Wilson
fuente
7

JSON es bastante nuevo y los sistemas heredados no lo admitirán. La actualización de los sistemas heredados es costosa e introduce errores. JSON no reemplazará XML en ningún momento en el futuro cercano.

Tom Squires
fuente
2
gracias por su respuesta. Lo que tengo en mente es una revisión técnica, en lugar de una estrategia de implementación. Solo quiero saber, por ejemplo, para las nuevas versiones de esos sistemas heredados, ¿podemos eliminar XML por completo y usar JSON? Si no, ¿qué extrañamos en JSON?
Saeed Neamati
Por otro lado, no he usado ningún XML, solo JSON, en los últimos años. Y buen viaje. Por supuesto, XML es más emprendedor. Lo cual es excelente para la seguridad laboral, no tan bueno para la eficiencia.
gnasher729
6

Yo diría que cwallenpoole hace un excelente punto. Si bien la mayoría de XML se puede traducir a JSON, si hacerlo es mejor es un punto separado.

JSON se presta a estructuras de datos al menos tan bien como XML y probablemente mejor, pero XML lee mucho más naturalmente que JSON al marcar documentos textuales, donde las etiquetas se usan dentro de un flujo de texto más amplio en lugar de simplemente como una forma de delimitar una jerarquía de campos.

Si bien HTML 5 puede tener su propio analizador, eso todavía deja aplicaciones como DocBook.

ssokolow
fuente
JSON obviamente puede contener cadenas que pueden contener HTML.
gnasher729
6

Depende del dominio. En términos de servicios web? Absolutamente. Es completamente vergonzoso que los proveedores sigan presionando a SOAP a sus clientes. REST + JSON hasta el final.

Ahora, cuando habla de datos complejos y estructurados con información de estilo como Docbook u otra implementación. Ese es un dominio adecuado para XML.

Jason Lewis
fuente
4

¿Por qué limitarse a JSON cuando YAML es un superconjunto y mucho más expresivo y, por lo tanto, más potente que XML o JSON?

Dicho esto, si usa los marcos de serialización correctos, debería poder serializar y deserializar todos los formatos mencionados anteriormente con un par de líneas de código simples.


fuente
3

Se pone feo cuando intentas modelar estos dos objetos en JSON:

<customer><name>John Doe</name></customer>
<employee><name>John Doe</name</employee>

Usando JSON como solía hacerlo en el 99% de los casos, uno se pierde con:

{ name: "John Doe" } 

Y ahora tienes que agregar algunas metaestructuras y toda la belleza de JSON desaparece mientras te quedas con las desventajas.

Michal Till
fuente
11
el JSON equivalente a su XML proporcionado es { customer: { name: 'John Doe' }, employee : { name: 'John Doe' } }. Entonces, técnicamente, su respuesta no es correcta. :)
Saeed Neamati
Claro, lo único que falta en JSON son los atributos, y son inútiles para modelar objetos (a diferencia del marcado). A veces, los atributos se usan como un acceso directo para lo que se puede expresar usando datos anidados (por ejemplo, en archivos de configuración de Hibernate), lo cual es útil pero en realidad la existencia de la elección lo hace más difícil. Los archivos de configuración y los objetos de modelado son dos lugares donde JSON es claramente superior.
maaartinus
2
@SaeedNeamati, entonces, ¿cómo modelarías <customer><name>John Doe</name></customer><customer><name>John Doe</name></customer>en JSON?
svick
66
{clientes: [{nombre: 'John Doe'}, {nombre: 'John Doe'}]}?
scrwtp
2
@Stijn: correcto, y eso funciona, pero confirma el comentario de la respuesta original, que "tienes que agregar algunas metaestructuras" para modelar ciertas cosas que caen más naturalmente en XML.
Matt R
3

No sé si existe tal instalación para JSON, pero en .NET al menos puede validar XML contra un esquema dado. Esa es una valiosa ventaja de XML en mis ojos.

Grant Palin
fuente
2
json también tiene esquemas: json-schema.org
lordvlad