¿Qué es más recomendable usar JSON o XML? - Educa Sistemas

Breaking

Post Top Ad

Post Top Ad

lunes, 4 de diciembre de 2017

¿Qué es más recomendable usar JSON o XML?

Que tal colegas, ¿Como estan?
En este dia les traemos una pequeña opinion acerca de  dos grandes opciones a utilizar  una de ellos JSON  y por otra aprte XLML.


imagen de https://camo.githubusercontent.com

les dejamos la opinion generalizada, si tienen otro punto de vista favor de comentar.

La finalidad más o menos explícita de XML consistía en usar e intercambiar información sin ser esclavo de los motores de bases de datos relacionales de la época en que XML fue creado. Es decir, se quería crear un estándar. Y se convirtió de facto en un estándar aceptado por la industria y las grandes instituciones internacionales.
Pero, ¿cuál era el gran problema de XML? Los esquemas. Yo puedo hablarte de mi campo de trabajo, que es el mundo bancario y financiero. El XML para el mundo financiero se denomina XBRL. En la década del 2000, hubo una lucha tremenda por tratar de implantarlo a nivel global, pero el mundo anglosajón no llegó a aceptarlo nunca y, prácticamente, ha caído en desuso.
¿Cuál fue la causa de la no aceptación? La complejidad de los esquemas. Ese es, en síntesis, el gran problema de XML. Los DTDs y demás parafernalia alcanzaron, en el caso que yo conozco, tal grado de complejidad, que no eran operativos.

¿Cuál es la ventaja de JSON? La simplicidad del modelo de intercambio, y el hecho de que se adapta como un guante a las nuevas bases de datos no relacionales, como mongoDB y otras. Además, es perfecto para ser utilizado con Javascript, Python y otros lenguajes modernos. Por eso está triunfando.
Como alguien ya ha comentado, si no tienes sistemas legacy (sistemas heredados) con los que trabajar, desde luego mi recomendación es JSON. Ahora, si trabajas en una empresa veterana, que se haya “comido” mucho XML, no te quedará más remedio que tratar con él. Pero, en mi opinión, es un muerto.
XML nació primero , un poco el resultado evolutivo de HTML. Con XML fueron surgiendo las herramientas base: XPath (para consultar la estructura de XML), el uso de XSL / XSLT 1.0 y 2.0 (para las transformaciones), los conceptos de namespaces…, el DTD (validadores para estructuras XML) y otras más que se me escapan al detalle.
Como resultado, XML se volvió un mundo muy rico… y en extremo complejo. El uso de tags, las estructuras anidadas, declaraciones en el cabezal, namespaces, atributos, dtds, versiones diferentes de xml, y el overhead asociado al uso continuo de ‘tags’ por todas partes oscurecieron el objetivo de XML .
A los efecto prácticos, XML es increíblemente flexible, con un costo(muy) alto. Este costo está asociado a cuanto esfuerzo (lease: conocimiento adicional) nos significa operar con los documentos para transformarlos a nuestras necesidades.
Este esfuerzo se traduce en una curva de aprendizaje empinada. (XSL es un conjunto de reglas de transformación y no es precisamente un lenguaje en si, ni ofrece la lógica de un lenguaje en muchos casos).
Durante los 15 años que conozco XML, cuento con los dedos de UNA mano los desarrolladores que entendían XML y XSL como para hacer operaciones complejas. Ni hablemos de depurar una hoja de transformaciones XSL. Hacer una consulta XPath de mediana complejidad en un documento XML con múltiples namespaces requiere buenos fundamentos.
Y el mercado de desarrollo , que continuamente está evolucionando, no paga por estas minucias. Un profesional ya está demasiado atareado aprendiendo lenguajes, entornos de desarrollos y lidiando con su vida como para aprender 2 o 3 pseudo lenguajes adicionales solo para manejar más datos.
Esta dificultad inherente, en mi opinión , marcó una línea divisoria que pocos desarrolladores se molestaron en cruzar. Y cuando hay varias alternativas que resuelven el mismo problema, es natural decantarse por el camino más sencillo.
JSON nació como una necesidad de intercambio de datos, bastante menos ambiciosa y más simple. He trabajado con JSON y es probable que si hubiera aparecido un poco antes, hubiese el seguido the JSON-path y hubiese dejado XML atrás.
Respondiendo a la pregunta:
Si estás en un proyecto que controlas de punta a punta y el tiempo apremia, JSON es la respuesta.
Si estás en proyectos que requieren invocaciones a Web services (especialmente viejos web services) saber XML te va dar una buena mano.
Si estas trabajando con documentos XML , no hay JSON que te ayude.
Si tienes que crear estructuras de datos que es preciso extraer información puntual sin programación adicional, XML. Pero por otra parte si sabes algún lenguaje de programación para empezar , quizá es más sano un programa de parsing o querying + JSON. Está disyuntiva es la que ha decidido JSON sobre XML.
Diría que CUALQUIER estructura de datos que se codifique en XML puede convertirse en JSON y viceversa. XML lo que tiene es que las herramientas de recuperación (Xpath) y transformación (XSL) son mucho más sofisticadas y permiten SIN PROGRAMAR obtener resultados.
Tip adicionales:
  • La mejor herramienta que he manejado para XML es XMLSpy . Por LEJOS, la mejor. Las últimas versiones soportan JSON indistintamente (lo cual es notable, aunque no lo he probado aún)
  • Si trabajas en Javascript, JSON es mágico, ya se provee varias funciones nativas al respecto.
  • Siempre intenta buscar la solución más simple a un problema. Se que es raro que las soluciones más simples se presenten primero…
 

Post Top Ad

Responsive Ads Here