Una mirada profunda a JSON frente a XML, Parte 3: XML y el futuro de JSON

Publicado: 2022-03-11
Relacionado: Una mirada profunda a JSON vs. XML, Parte 2: Las fortalezas y debilidades de ambos

En la Parte 2 de este artículo, analizamos más de cerca JSON como intercambio de datos y evaluamos sus fortalezas y debilidades para aplicaciones simples versus las complejas. JSON se destaca como el formato legible por humanos más conciso y compacto, pero su simplicidad básica puede tener implicaciones no deseadas cuando se usa para casos de uso complejos. Con JSON como intercambio de datos, los desarrolladores se quedan solos para implementar las funcionalidades que faltan en JSON, lo que da como resultado soluciones acopladas y no estándar que intentan llenar el vacío. Para las soluciones empresariales que insisten en afirmar un funcionamiento sin errores, el uso de JSON puede dar lugar a patrones no deseados que pueden obstaculizar la calidad del código del sistema, la estabilidad y la resistencia a futuras incógnitas. ¿XML ofrece capacidades para ayudar a las aplicaciones a mitigar este riesgo? ¿Se pueden lograr las mismas funcionalidades con JSON? Una mirada más cercana a XML como intercambio de datos revelará sus fortalezas para reducir el riesgo del software y brindará a los desarrolladores una mejor comprensión de los patrones que podrían ayudar a mejorar la calidad de sus aplicaciones.

En la Parte 3 de este artículo, haremos lo siguiente:

  1. Explore XML como intercambio de datos y evalúe sus fortalezas para admitir requisitos complejos.
  2. Analice el futuro de JSON y explore soluciones que traigan las fortalezas de XML a JSON para permitir a los desarrolladores crear software que sea más estable y más resistente a errores y futuras incógnitas.
Relacionado: Una mirada profunda a JSON frente a XML, Parte 1: La historia de cada estándar

XML se etiqueta fácilmente como la alternativa compleja y detallada a JSON. El sitio web w3schools.com, una referencia popular para los estándares web, ofrece solo 58 palabras sobre el tema "Por qué JSON es mejor que XML" 1 . Una evaluación tan simplista de JSON frente a XML es engañosa, porque XML proporciona mucho más que un simple intercambio de datos. De hecho, XML no se diseñó solo para el intercambio de datos, sino como un lenguaje para especificar lenguajes de marcado personalizados para cualquier aplicación. Con su semántica estricta, XML definió un estándar para afirmar la integridad de los datos de los documentos XML, de cualquier sublenguaje XML. Muchos desarrolladores creen que “XML falló y fue reemplazado por JSON”, pero esto no podría estar más lejos de la realidad. Originalmente, XML se concibió para ser utilizado para todos los problemas de interoperabilidad de datos, y hasta el día de hoy sigue siendo "el formato más utilizado en el mundo para representar e intercambiar información". 2

JSON es simple y XML es poderoso

En la Parte 2 de este artículo, exploramos el intercambio de datos que implica contratos impulsados ​​por el consumidor (CDC), la evolución del protocolo y la validación de mensajes. Con JSON como intercambio de datos, nuestro ejemplo, el Banco Europeo, se enfrentó al desafío de proporcionar una solución de riesgo mitigado para el intercambio de datos con los minoristas. El banco deseaba patrones de software que dieran como resultado un bajo acoplamiento, un alto encapsulamiento y una alta resiliencia frente a futuras incógnitas. Sin embargo, con JSON como intercambio de datos, al banco se le presentaron patrones que resultaron en lo contrario: baja encapsulación, alto acoplamiento y una menor resistencia a futuras incógnitas.

Revisemos el ejemplo del Banco Europeo y reemplacemos JSON como formato de intercambio de datos con XML. Los siguientes mensajes XML son equivalentes al mensaje JSON para cada tipo de identificador de cuenta: SWIFT, IBAN y ACH.

 <message xsi:type="swift" xmlns="urn:bank:message" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <code>CTBAAU2S</code> </message> <message xsi:type="iban" xmlns="urn:bank:message" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <code>DE91 1000 0000 0123 4567 89</code> </message> <message xsi:type="ach" xmlns="urn:bank:message" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <code>379272957729384</code> <routing>021000021</routing> </message>

A pesar de la pérdida inmediata en la eficiencia del recuento de bytes sin procesar, XML justifica su verbosidad al admitir un alcance más amplio en torno al intercambio de datos. Al codificar los datos con JSON, pudimos resolver los requisitos inmediatos del intercambio de datos, pero nada para admitir múltiples variantes de mensajes o su validación. Para abordar el alcance que rodea a los contratos impulsados ​​por el consumidor, los desarrolladores necesitarían implementar un código personalizado que resulte en un acoplamiento lógico entre el formato del mensaje, su contenido y la implementación funcional para su procesamiento. Alternativamente, el desarrollador podría optar por armar un rompecabezas de una colección de bibliotecas y marcos para cumplir con los requisitos más altos. Ambos enfoques dan como resultado una cebolla de capas sobre el intercambio de datos que se acoplan directamente a la aplicación. Sin embargo, al codificar los datos con XML, podemos resolver muchos de los requisitos sin el acoplamiento.

Los equivalentes de mensajes XML utilizan dos características particulares del estándar XML: espacios de nombres y tipos de instancias. El atributo xmlns="urn:bank:message" especifica el espacio de nombres del mensaje, y el "xsi:type" especifica su tipo de instancia, como "swift" , "iban" o "ach" . Estos dos atributos son estándares XML que permiten que un procesador de mensajes identifique el tipo de mensaje, así como anular la referencia al esquema que define las reglas de validación.

El esquema XML representa el diferenciador clave entre JSON y XML. Con un esquema, un desarrollador puede encapsular la definición normativa del formato del mensaje en un medio separado de la aplicación y definir restricciones de valor proporcionando reglas de validación impuestas por los procesadores XML. Un esquema de ejemplo para el Banco Europeo (con espacio de namespace: xmlns="urn:bank:message" ), completo con descriptores de tipo y restricciones de valor, es el siguiente documento de esquema XML (XSD):

 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" xmlns="urn:bank:message" targetNamespace="urn:bank:message"> <xs:complexType name="format" abstract="true"/> <xs:complexType name="swift"> <xs:complexContent> <xs:extension base="format"> <xs:sequence> <xs:element name="code"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:pattern value="[AZ]{6}[A-Z0-9]{2}([A-Z0-9]{3})?"/> </xs:restriction> </xs:simpleType> </xs:element> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="iban"> <xs:complexContent> <xs:extension base="format"> <xs:sequence> <xs:element name="code"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:pattern value="[AZ]{2}\d{2} ?\d{4} ?\d{4} ?\d{4} ?\d{4} ?\d{0,2}"/> </xs:restriction> </xs:simpleType> </xs:element> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="ach"> <xs:complexContent> <xs:extension base="format"> <xs:sequence> <xs:element name="code"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:pattern value="\w{1,17}"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="routing"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:pattern value="\d{9}"/> </xs:restriction> </xs:simpleType> </xs:element> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="message" type="format"/> </xs:schema>

Este esquema XML es lógicamente equivalente a la isValid(message) de la Parte 2. A primera vista, este esquema XML es considerablemente más detallado que isValid(message) . Sin embargo, la diferencia fundamental entre los dos es que isValid(message) está acoplado a la aplicación y el esquema XML no. El esquema XML es un lenguaje para expresar restricciones sobre documentos XML y existen varios lenguajes de esquema diferentes de uso generalizado, los principales de los cuales son: definiciones de tipo de documento (DTD), Relax-NG, Schematron y definiciones de esquema XML W3C (XSD). ). 3 Para el Banco Europeo, el esquema XML proporciona una solución de riesgo reducido para los requisitos de nivel superior sin el acoplamiento.

Un esquema XML da como resultado un menor riesgo de software. Con XML, las reglas para la validación de mensajes se expresan en un lenguaje de esquema que se separa de la aplicación y, por lo tanto, no se acopla a ella. Dado que el esquema XML está completamente separado del sistema, el significado lógico del formato del mensaje y la implementación funcional para su procesamiento están desacoplados. El esquema XML le brinda al Banco Europeo una capa encapsulada que es la única responsable del contexto de validación, variabilidad, versiones y más del mensaje.

El esquema XML representa la definición normativa del contrato impulsado por el consumidor. Para el Banco Europeo, esto proporciona un enfoque de riesgo mitigado para reducir $\xi_0$ más cerca de 0. Dado que el esquema está desvinculado del banco y el minorista, ambas partes pueden usarlo para validar y hacer cumplir el contrato.

texto alternativo
El contrato impulsado por el consumidor se especifica en un esquema XML, lo que proporciona una definición normativa de las reglas de cumplimiento que cada parte puede ejercer. Dado que el XSD está desacoplado de la aplicación, se puede compartir con cada participante en el protocolo.

¿Por qué el esquema XML es tan detallado?

La especificación del esquema XML proporciona un lenguaje para que los desarrolladores implementen patrones lógicos y estructurales utilizados para definir y restringir todas las partes constituyentes de cualquier documento XML. Con un esquema XML, los desarrolladores pueden incrustar un significado más profundo en cada parte estructural y lógica de un documento XML. Por ejemplo, el esquema XML permite:

  1. Definición de restricciones de expresión regular para cadenas constituyentes,
  2. Definición de rangos y formatos para números constituyentes,
  3. Definición de elementos constitutivos y atributos requeridos y opcionales,
  4. Definición de requisitos clave y de referencia en un documento, y mucho, mucho más.

Con un esquema XML, un sistema puede confiar en validadores XML genéricos para afirmar la validez de cada mensaje de entrada, reduciendo intrínsecamente el "espacio de error" $\xi_0$ más cerca de 0 y aislando automáticamente la lógica comercial de entradas erróneas.

El riesgo del desarrollo futuro

Los sistemas pueden utilizar características inherentes de la especificación XML para reducir el riesgo de desarrollo futuro del software. Al acordar un contrato normativo en forma de esquema XML, los sistemas definen las reglas y restricciones para que se intercambien todos los objetos y propiedades (elementos y atributos, para XML). A partir de entonces, los sistemas pueden aprovechar el alcance más amplio de la especificación de XML para abordar la variabilidad de los mensajes, el control de versiones del protocolo y la validación del contenido. Por ejemplo, los espacios de nombres XML proporcionan mensajes XML con la información necesaria para:

  1. Identificar la versión del mensaje.
  2. Desreferenciar el esquema del contrato normativo.
  3. Validar la corrección de un documento.

Con la amplia gama de características y capacidades que ofrece el esquema XML, la mayoría de los requisitos complejos relacionados con el intercambio de datos se pueden resolver con el propio XML. A esto se refería el Dr. Charles Goldfarb cuando dijo que “[XML es] el santo grial de la informática”. 4

El esquema XML ayuda a que las aplicaciones sean resistentes a los errores y maleables a cambios futuros.

XML es una especificación ampliamente aceptada y minuciosamente examinada con innumerables bibliotecas disponibles para todas las plataformas para ayudar en el procesamiento y validación de documentos XML. Con XML como formato de intercambio de datos, un desarrollador puede resolver los requisitos inmediatos, así como los relacionados con los contratos impulsados ​​por el consumidor, la variabilidad de mensajes, el control de versiones de protocolos y la validación de contenido. XML permite a un desarrollador cubrir el riesgo de requisitos complejos y, lo que es más importante, de futuras incógnitas.

XML es mucho más que el intercambio de datos y se puede utilizar para abordar problemas mucho mayores que con JSON. Cuando se ve desde esta perspectiva, el ámbito de XML cubre una mayor parte de la cebolla, por lo que varias de las capas de la cebolla están contenidas en el propio ámbito de XML.

texto alternativo
un. XML como intercambio de datos.
B. Validación de mensajes encapsulados con un esquema XML. Este código está desacoplado de la aplicación.
C. Validación de mensajes no encapsulados. Este código se entremezcla con las capas comerciales.
D. La aplicación.

Al elegir el mejor formato de intercambio de datos para una aplicación, ¿es solo el centro de la cebolla lo que nos importa o es la cebolla en su totalidad?

Las diferencias fundamentales entre JSON y XML

XML ofrece mucho más que el intercambio de datos y se puede utilizar para abordar problemas mucho mayores que con JSON. El alcance de los requisitos complejos que rodean el intercambio de datos se adapta a XML, lo que permite que los sistemas utilicen bibliotecas y marcos que se ajusten a un estándar, desacoplados de la aplicación.

XML es una especificación que aborda el alcance de los requisitos complejos por diseño y es un estándar definido por el W3C y respaldado por todos los proveedores de software y plataformas de lenguaje relevantes. Al usar XML como intercambio de datos, las aplicaciones se benefician automáticamente de una reducción sistemática del riesgo del software.

El futuro de JSON

Sin lugar a dudas, JSON llegó para quedarse. Con JavaScript como la plataforma de desarrollo más utilizada en la actualidad, JSON se ha convertido en el formato de intercambio de datos más destacado. Para proyectos pequeños con baja complejidad, JSON encaja perfectamente. Pero a medida que nos esforzamos por crear aplicaciones mejores y más grandes para el futuro, la complejidad general de nuestro software está destinada a aumentar. Con las poderosas capacidades de XML como ejemplo, varios grupos se han esforzado por inventar estándares similares para JSON.

La deficiencia fundamental de JSON es que no proporciona un estándar general para la descripción normativa de los constituyentes lógicos de sus documentos.

Esquema JSON

En 2009, un grupo inició el esquema JSON 5 , que es un vocabulario para anotar y validar documentos JSON. El esquema JSON usa la semántica JSON para definir un conjunto de reglas y restricciones para los constituyentes de los documentos JSON, y varios proyectos en varias plataformas han implementado bibliotecas que admiten la especificación del esquema JSON. Aunque todavía no es un estándar oficial, el proyecto de esquema JSON proporciona una solución a una serie de requisitos que es similar a la especificación del esquema XML. Con el vocabulario del esquema JSON, los desarrolladores pueden definir las reglas y restricciones lógicas y estructurales de los documentos JSON. Luego, el esquema se puede usar para ayudar en el procesamiento y la validación de documentos JSON con bibliotecas que están desacopladas de la aplicación, lo que reduce la necesidad de entremezclar código sin encapsular en la aplicación. Con el esquema JSON, un desarrollador puede elegir JSON como el formato de su intercambio de datos y abordar, de una manera mitigada por el riesgo, los requisitos complejos que anteriormente no se podían abordar solo con JSON.

El proyecto de esquema JSON es un esfuerzo de la comunidad y, después de una década de revisiones, se erige como la especificación predominante para los esquemas JSON. Aunque todavía no es un estándar, la popularidad del proyecto de esquema JSON indica el nivel de interés por tal solución. Conceptualmente, la especificación del esquema JSON se asemeja al esquema XML, pero una comparación de los dos revela diferencias entre sus modelos, capacidades y semántica. Por ejemplo, aunque el lenguaje define una amplia gama de propiedades para restringir los límites de los tipos de valor JSON, sus numerosos atributos permiten la expresión de definiciones de esquema que se contradicen a sí mismas.

Por ejemplo, el siguiente extracto define un tipo de "object" que contiene tres propiedades: "number" , "street_name" y "street_type" .

 { "type": "object", "properties": { "number": { "type": "number" }, "street_name": { "type": "string" }, "street_type": { "type": "string", "enum": ["Street", "Avenue", "Boulevard"] } } }

La definición de un tipo de "object" acepta restricciones adicionales, una de las cuales es "minProperties" . Al modificar la definición de tipo de "object" anterior con "minProperties": "4" , la definición deja de tener sentido, porque solo se definen explícitamente tres propiedades para el objeto.

El esquema JSON tiene una cantidad considerablemente grande y amplia de propiedades de restricción, muchas de las cuales son esenciales para confinar documentos JSON de manera efectiva y muchas de las cuales se superponen entre sí. Con propiedades de restricción que se superponen en significado, el vocabulario del esquema JSON presenta dos familias de desafíos:

  1. Requiere una mayor curva de aprendizaje por parte de los desarrolladores, debido al amplio vocabulario y los matices inusuales o poco convencionales en su semántica.
  2. Es más difícil de implementar para las bibliotecas de validación, lo que lleva a soluciones que implementan las áreas grises de manera diferente, lo que resulta en implementaciones inconsistentes.

El lenguaje de esquema XML en sí mismo no está completamente libre de permitir la expresión de definiciones autocontradictorias, pero son muchas menos y limitadas. De hecho, la especificación del esquema XML se desarrolló prestando mucha atención tanto a la facilidad de uso para los desarrolladores como a las bibliotecas que implementan la especificación. Además, el proyecto de esquema JSON solo define la especificación del lenguaje de esquema, pero existen muchos proyectos comunitarios que implementan esta especificación.

El validador de esquema JSON 6 es un proyecto popular que implementa un validador de esquema JSON para la plataforma Java. Al integrar esta biblioteca en una aplicación Java, la aplicación puede afirmar la conformidad de todos los documentos JSON intercambiados. Hay otras implementaciones de la especificación del esquema JSON disponibles para una variedad de plataformas.

Para el Banco Europeo, usemos el esquema JSON para implementar un esquema para mensajes JSON con identificadores de cuenta.

 { "$schema": "http://json-schema.org/draft-07/schema#", "definitions": { "swift": { "type": "object", "properties": { "type": { "type": "string", "pattern": "swift" }, "code": { "type": "string", "pattern": "(\\([0-9]{3}\\))?[0-9]{3}-[0-9]{4}" }, "required": ["type", "code"] } }, "iban": { "type": "object", "properties": { "type": { "type": "string", "pattern": "iban" }, "code": { "type": "string", "pattern": "[AZ]{2}\\d{2} ?\\d{4} ?\\d{4} ?\\d{4} ?\\d{4} ?\\d{0,2}" }, "required": ["type", "code"] } }, "ach": { "type": "object", "properties": { "type": { "type": "string", "pattern": "ach" }, "code": { "type": "string", "pattern": "\\w{1,17}" }, "routing": { "type": "string", "pattern": "\\d{9}" }, "required": ["type", "code", "routing"] } } } }

Este esquema JSON define los 3 tipos de objetos: "swift" , "iban" y "ach" . Especifica patrones de expresiones regulares para afirmar que la información de la cuenta no es válida y declara "type" y "code" como propiedades requeridas para cada tipo, además de "routing" como propiedad requerida para el tipo "ach" . Con este esquema JSON, el Banco Europeo puede validar su entrada JSON para afirmar que el contenido del mensaje es correcto para cada interacción.

El esquema JSON brinda muchas capacidades de XML a JSON, pero aún es un trabajo en progreso. Aunque es una gran solución que se puede usar para cubrir el riesgo del software, la especificación del esquema JSON no es perfecta. Debido a la evolución informal de su lenguaje, el lenguaje ha evolucionado en una dirección que omite características posiblemente importantes y contiene patrones de expresión lógicos y estructurales que son confusos y poco convencionales. Por ejemplo, el lenguaje de esquema no tiene la capacidad de definir tipos abstractos, lo que puede llevar a los desarrolladores a implementar soluciones complicadas que resultan en un riesgo de software asociado propio. 7

El proyecto de esquema JSON ha aportado una valiosa contribución a los conceptos detrás de un lenguaje de esquema para JSON. A pesar de las deficiencias en la claridad de su semántica, el lenguaje de esquemas JSON es una solución versátil que aporta muchas capacidades de XML a JSON.

Para ver más de cerca la especificación del esquema JSON, consulte Comprensión del esquema JSON.

JSONx

En 2014, otro grupo inició el proyecto JSONx, que aprovecha directamente XML para brindar una solución igualmente poderosa para JSON. El proyecto JSONx se creó específicamente para la empresa y define el lenguaje de definición de esquemas JSON (JSD), que se modela de forma similar a la especificación del esquema XML. Utilizando el esquema XML como modelo, el JSD define patrones estructurales y lógicos que guardan un gran parecido con el lenguaje de definición de esquemas XML.

Para el ejemplo del Banco Europeo, usemos el lenguaje JSD para implementar un esquema para mensajes JSON con identificadores de cuenta.

 { "jx:ns": "http://www.jsonx.org/schema-0.3.jsd", "jx:schemaLocation": "http://www.jsonx.org/schema-0.3.jsd http://www.jsonx.org/schema-0.3.jsd", "message": { "jx:type": "object", "abstract": true }, "swift": { "jx:type": "object", "extends": "message", "properties": { "type": { "jx:type": "string", "pattern": "swift", "nullable": false }, "code": { "jx:type": "string", "pattern": "[AZ]{6}[A-Z0-9]{2}([A-Z0-9]{3})?", "nullable": false, "use": "required" } } }, "iban": { "jx:type": "object", "properties": { "type": { "jx:type": "string", "pattern": "iban", "nullable": false }, "code": { "jx:type": "string", "pattern": "[AZ]{2}\\d{2} ?\\d{4} ?\\d{4} ?\\d{4} ?\\d{4} ?[\\d]{0,2}", "nullable": false } } }, "ach": { "jx:type": "object", "properties": { "type": { "jx:type": "string", "pattern": "ach", "nullable": false }, "code": { "jx:type": "string", "pattern": "\\w{1,17}", "nullable": false }, "routing": { "jx:type": "string", "pattern": "\\d{9}", "nullable": false } } } }

A primera vista, el esquema JSD es similar en expresión al esquema JSON. Sin embargo, una diferencia es la semántica concisa del JSD en comparación con el esquema JSON. Específico para este ejemplo, el JSD coloca la propiedad "use": "required" en la definición que se especifica, mientras que el esquema JSON asocia esta propiedad con el objeto principal, lo que requiere que el nombre de los valores coincida con el nombre de la definición de la propiedad. La restricción "use": "required" solo se especifica en la propiedad "code" del objeto "swift" y se omite de los demás porque "use": "required" es el valor predeterminado. El lenguaje JSD se diseñó teniendo en cuenta todos estos matices y ofrece una solución limpia e intuitiva para la expresión de esquemas JSON.

Desde el inicio, una propiedad distintiva del proyecto JSONx es su intención principal de brindar claridad y utilidad a los desarrolladores. Para lograr esto, una característica poderosa de JSD es su convertibilidad a JSDx: el lenguaje JSD se puede expresar en archivos JSON y XML. Ambos formularios son traducibles uno a uno y brindan a los desarrolladores la capacidad de usar herramientas de edición XML avanzadas para ayudar en la creación de documentos JSD para ser validados en vivo y sin errores.

El esquema JSD de arriba se puede expresar en el siguiente formulario JSDx:

 <schema xmlns="http://www.jsonx.org/schema-0.3.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.jsonx.org/schema-0.3.xsd http://www.jsonx.org/schema-0.3.xsd"> <object name="swift"> <property name="code" xsi:type="string" pattern="[AZ]{6}[A-Z0-9]{2}([A-Z0-9]{3})?" nullable="false" use="required"/> </object> <object name="iban"> <property name="code" xsi:type="string" pattern="[AZ]{2}\d{2} ?\d{4} ?\d{4} ?\d{4} ?\d{4} ?\d{0,2}" nullable="false"/> </object> <object name="ach"> <property name="code" xsi:type="string" pattern="\w{1,17}" nullable="false"/> <property name="routing" xsi:type="string" pattern="\d{9}" nullable="false"/> </object> </schema>

La forma JSDx de JSD es poderosa porque proporciona una especificación clara, autovalidante y de riesgo reducido para definir esquemas JSON.

El lenguaje JSD está diseñado para abordar las preocupaciones de las definiciones que se contradicen a sí mismas y se basa en patrones estándar para la expresión de restricciones. Diseñado en gran semejanza con el lenguaje de definición de esquemas XML (XSD), las declaraciones de tipo JSD y las definiciones de restricciones se parecen mucho a las estructuras equivalentes en XML. La especificación JSD(x) proporciona una solución completa para la definición de restricciones estructurales y lógicas, y se describe a sí misma, proporcionando una definición normativa del lenguaje JSD(x) expresado en el propio lenguaje JSD(x). Para ver más de cerca la especificación JSD(x), consulte Lenguaje de definición de esquemas JSON.

Además del lenguaje JSD(x), el proyecto JSONx proporciona implementaciones de referencia de procesadores y validadores JSD(x), así como una API de vinculación de clases y un generador de código para la plataforma Java. Con la API de vinculación y el generador, un desarrollador puede usar un esquema JSD(x) para generar automáticamente clases para las definiciones de objetos en el esquema deseado, que se puede usar para analizar y clasificar documentos JSON que se ajusten al esquema. Las clases generadas proporcionan un enlace fuertemente tipado entre el esquema y la plataforma Java, que representa el uso, las restricciones y las relaciones especificadas en el esquema. Con enlaces fuertemente tipados al esquema, la aplicación reduce aún más el riesgo del software relacionado con futuras modificaciones que podrían resultar en incompatibilidades.

Al aprovechar el compilador de Java, los enlaces fuertemente tipados identifican las incompatibilidades con los errores en tiempo de compilación, reduciendo efectivamente el riesgo de errores relacionados con el procesamiento de mensajes a casi cero. Este patrón de ingeniería permite a los desarrolladores implementar cambios y resolver incompatibilidades de forma rápida y segura, sin tener que depender del tiempo de ejecución para encontrar errores o casos de falla, y especialmente sin tener que depender de que los usuarios encuentren los errores por sí mismos. La API de vinculación se implementa con anotaciones de Java, lo que permite vincular cualquier clase a un esquema JSD(x) con tipos fuertes, pero de forma ligera. Las capacidades de generación de código y vinculación fuertemente tipada de JSONx admiten el alcance completo de la especificación JSD(x), diseñada específicamente para cumplir con los altos estándares de las soluciones empresariales.

El marco JSONx se creó para soluciones empresariales y ofrece un alto estándar de calidad y utilidad para sistemas complejos, además de facilidad de uso y validación de errores en tiempo de edición para desarrolladores.

El motor de vinculación, el procesador y el validador JSD(x) informan una cobertura de prueba del 87 %, lo que permite a los desarrolladores de Java integrar con confianza el marco para vincular esquemas JSD(x) a sus aplicaciones Java y codificar, decodificar y validar documentos JSON. Para ver más de cerca el marco JSONx para Java, consulte Marco JSONx para Java.

Conclusión

Con una mirada más profunda a la historia de la web y las tendencias de software en los últimos años, podemos ver una estrecha relación entre la proliferación de JavaScript y la popularidad de JSON. Muchos artículos y publicaciones de blog ofrecen una perspectiva limitada al comparar JSON y XML, lo que lleva a los lectores a descartar XML como obsoleto y deja a muchos sin darse cuenta de las poderosas capacidades que pueden ayudarlos a mejorar la arquitectura de su software, la resiliencia de su software al cambio y la calidad general y estabilidad del software en su conjunto. Con una evaluación más profunda de las fortalezas y debilidades de cada estándar, los desarrolladores pueden estar empoderados para tomar mejores decisiones para sus proyectos.

Al igual que la "catástrofe de la divergencia" con HTML que condujo a la invención de XML, se observa un efecto similar en las bases de código complejas que dependen de JSON para el intercambio de datos. La especificación JSON no encapsula las funcionalidades inmediatas que rodean el intercambio de datos, lo que puede provocar la fragmentación de la lógica en las capas superiores de la aplicación. Sin embargo, con XML, los desarrolladores pueden llevar la complejidad que rodea el intercambio de datos a las capas inferiores de la aplicación, lo que da como resultado la capacidad de detectar errores antes en el ciclo de vida de la aplicación. Especialmente para los lenguajes compilados, en combinación con un marco de enlace, las arquitecturas que se basan en el enlace XML pueden reducir el potencial de errores relacionados con los datos a casi cero. Para la empresa, son estas poderosas capacidades en la reducción sistemática del riesgo del software las que hacen de XML el "santo grial de la informática".

JSON llegó para quedarse y varios proyectos están cobrando impulso para ofrecer las potentes capacidades de XML a JSON. El proyecto de esquema JSON ofrece una especificación de esquema desarrollada por la comunidad que ha crecido orgánicamente para admitir una amplia gama de atributos y patrones declarativos para describir y restringir documentos JSON. El proyecto JSONx ofrece un lenguaje de esquemas de nivel empresarial que está diseñado de forma muy similar al lenguaje de definición de esquemas XML y ofrece formatos JSON y XML para la especificación de documentos de esquemas JSON. Con estas especificaciones y marcos, los desarrolladores pueden reducir el riesgo del software relacionado con los requisitos de capa superior relacionados con el intercambio de datos, como los contratos impulsados ​​por el consumidor, el control de versiones de protocolos, la validación de contenido y más.

Las funciones avanzadas de XML se diseñaron para mitigar el riesgo de software relacionado con los lenguajes de marcas. Los casos de uso con JSON no son diferentes, y un lenguaje de esquema es una solución comprobada y comprobada para cubrir sistemáticamente la amplia gama de riesgos de software que rodean el intercambio de datos.

Referencias

1. JSON frente a XML (w3schools.com, diciembre de 2016)

2. El éxito mundial que es XML (W3C, julio de 2018)

3. W3C - ¿Qué es un esquema XML? (W3C, octubre de 2009)

4. Internet: una enciclopedia histórica. Cronología, Volumen 3, pág. 130 (ABC-CLIO, 2005)

5. Esquema JSON (julio de 2008)

6. Validador de esquema JSON (GitHub)

7. JsonSchema y SubClassing (Horne, marzo de 2016)