A Deep Look at JSON vs. XML, Part 3: XML and the Future of JSON

In Part 2 of this article, we took a closer look at JSON as data interchange and evaluated its strengths and weaknesses for simple applications versus the complex. JSON stands out as the most concise, most compact human readable format, but its base simplicity can lead to unintended implications when used for complex use-cases. With JSON as data interchange, developers are left on their own to implement the functionalities that are missing from JSON itself, resulting in coupled and non-standard solutions that try to meet the gap. For enterprise solutions adamant in asserting error-free operation, the use of JSON may result in undesired patterns that can hamper the system’s code quality, stability, and the resilience to future unknowns. Does XML offer capabilities to help applications mitigate this risk? Can the same functionalities be achieved with JSON? A closer look at XML as data interchange will reveal its strengths in reducing software risk and provide developers a better understanding of the patterns that could help improve the quality of their applications.

In Part 3 of this article, we will:

1. Explore XML as data interchange and evaluate its strengths in supporting complex requirements.
2. Discuss the future of JSON and explore solutions that bring the strengths of XML to JSON to enable developers to build software that is more stable and more resistant to bugs and future unknowns.

XML is readily labeled as the complex and verbose alternative to JSON. The website w3schools.com—a popular reference for web standards—offers a mere 58 words on the subject of “Why JSON is better than XML”¹. Such a simplistic evaluation of JSON vs. XML is misleading, because XML provides a lot more than just data interchange. In fact, XML was not designed just for data interchange, but rather as language to specify custom markup languages for any application. With its strict semantics, XML defined a standard to assert data integrity of XML documents, of any XML sub-language. Many developers believe that “XML failed and was replaced with JSON,” but this could not be further from the truth. Originally, XML was envisioned to be used for all data interoperability problems, and to this day remains as “the world’s most widely-used format for representing and exchanging information.”²

JSON Is Simple, and XML Is Powerful

In Part 2 of this article, we explored data interchange involving consumer-driven contracts (CDCs), protocol evolution, and message validation. With JSON as data interchange, our example—European Bank—was challenged to provide a risk-mitigated solution for the interchange of data with retailers. The bank desired software patterns that resulted in low coupling, high encapsulation, and a high resilience to future unknowns. With JSON as data interchange, however, the bank was presented with patterns resulting in the opposite: low encapsulation, high coupling, and a lower resilience to future unknowns.

Let’s revisit the European Bank example and replace JSON as the data interchange format with XML. The following XML messages are equivalent to the JSON message for each account identifier type: SWIFT, IBAN, and 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>

Despite the immediate loss in raw byte count efficiency, XML justifies its verbosity by supporting a wider scope surrounding data interchange. By encoding the data with JSON, we were able to solve the immediate requirements of data interchange but nothing to support multiple message variants or their validation. To address the scope surrounding consumer-driven contracts, developers would need to implement custom code that would result in logical coupling between the message format, its content, and the functional implementation for its processing. Alternatively, the developer could choose to piece together a puzzle of a collection of libraries and frameworks to fulfill the higher requirements. Both approaches result in an onion of layers on top of data interchange that are coupled directly to the application. By encoding the data with XML, however, we are able to solve a lot move of the requirements without the coupling.

The XML message equivalents utilize two particular features of the XML standard: namespaces and instance types. The xmlns="urn:bank:message" attribute specifies the namespace of the message, and the "xsi:type" attribute specifies its instance type, as "swift", "iban", or "ach". These two attributes are XML standards that allow a message processor to identify the type of the message as well as to dereference the schema defining the validation rules.

The XML schema represents the key differentiator between JSON and XML. With a schema, a developer can encapsulate the normative definition of the message format in a medium separate from the application and define value constraints providing validation rules enforced by XML processors. An example schema for the European Bank (with namespace: xmlns="urn:bank:message"), complete with type descriptors and value constraints, is the following XML schema document (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="[A-Z]{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="[A-Z]{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>

This XML schema is logically equivalent to the isValid(message) function from Part 2. At first blush, this XML schema is considerably more verbose than isValid(message). The fundamental difference between the two, however, is that isValid(message) is coupled to the application, and the XML schema is not. The XML schema is a language for expressing constraints about XML documents and there are several different schema languages in widespread use, the main ones of which are: document type definitions (DTDs), Relax-NG, Schematron, and W3C XML schema definitions (XSD).³ For the European Bank, the XML schema provides a risk-reduced solution to higher-layer requirements without the coupling.

An XML schema results in lower software risk. With XML, the rules for validation of messages are expressed in a schema language that is disjoined from, and thus not coupled to, the application. Since the XML schema is fully detached from the system, the logical meaning of the message format and the functional implementation for its processing are decoupled. The XML schema gives the European Bank an encapsulated layer that is solely responsible for the context of message validation, variability, versioning, and more.

The XML schema represents the normative definition of the consumer-driven contract. For the European Bank, this provides a risk-mitigated approach to reduce $\xi_0$ closer to 0. Since the schema is decoupled from the bank and the retailer, both parties can use it to validate and enforce the contract.

Why Is the XML Schema So Verbose?

The XML schema specification provides a language for developers to implement structural and logical patterns used to define and to constrain all constituent parts of any XML document. With an XML schema, developers are able to embed deeper meaning into each structural and logical part of an XML document. For example, the XML schema allows for the:

1. Definition of regular expression constraints for constituent strings,
2. Definition of ranges and formats for constituent numbers,
3. Definition of required and optional constituent elements and attributes,
4. Definition of key and reference requirements in a document, and much, much more.

With an XML schema, a system can rely on generic XML validators to assert the validity of each input message, intrinsically reducing the “error space” $\xi_0$ closer to 0 and automatically insulating the business logic from erroneous inputs.

The Risk of Future Development

Systems can utilize inherent features of the XML specification to reduce the software risk of future development. By agreeing on a normative contract in the form of an XML schema, systems define the rules and constraints for all objects and properties (elements and attributes, for XML) to be interchanged. The systems are thereafter able to leverage the wider scope of XML’s specification to address message variability, protocol versioning, and content validation. For instance, XML namespaces provide XML messages with the information necessary to:

1. Identify the version of the message.
2. Dereference the normative contract schema.
3. Validate the correctness of a document.

With the wide breadth of features and capabilities offered by the XML schema, most of the complex requirements surrounding data interchange can be solved with XML itself. This is what Dr. Charles Goldfarb was referring to when he said “[XML is] the holy grail of computing.”⁴

The XML schema helps applications to be resilient to errors and malleable to future changes.

XML is a widely accepted and thoroughly vetted specification with countless libraries available for all platforms to aid in processing and validation of XML documents. With XML as the data interchange format, a developer is able to solve the immediate requirements as well as those concerning consumer-driven contracts, message variability, protocol versioning, and content validation. XML enables a developer to hedge the risk of complex requirements and, more importantly, of future unknowns.

XML is a lot more than data interchange and can be used to address problems much greater than with JSON. When seen from this perspective, the scope of XML covers a greater part of the onion, whereby several of the onion’s layers are contained in the scope of XML itself.

When choosing the best data interchange format for an application, is it only the center of the onion we care about, or is it the onion in whole?

The Fundamental Differences Between JSON and XML

XML offers a lot more than data interchange and can be used to address problems much greater than with JSON. The scope of complex requirements surrounding data interchange is accommodated by XML, allowing systems to utilize libraries and frameworks conforming to a standard, decoupled from the application.

XML is a specification that addresses the scope of complex requirements by design and is a standard defined by the W3C and supported by all relevant software vendors and language platforms. By using XML as data interchange, applications automatically profit from a systematic reduction of software risk.

The Future of JSON

JSON is undeniably here to stay. With JavaScript as the most widely used development platform today, JSON has become the most prominent data interchange format. For small projects with low complexity, JSON is a perfect fit. But as we endeavor to create bigger and better applications for the future, the general complexity of our software is destined to increase. With the powerful capabilities of XML as the example, several groups have endeavored to invent similar standards for JSON.

The fundamental deficiency of JSON is its lack in providing a general standard for the normative description of the logical constituents of its documents.

JSON Schema

In 2009, a group started the JSON schema⁵, which is a vocabulary to annotate and validate JSON documents. The JSON schema uses JSON semantics to define a set of rules and constraints for constituents of JSON documents, and several projects on various platforms have implemented libraries that support the JSON schema specification. Though not yet an official standard, the JSON schema project provides a solution to a scope of requirements that is similar to the XML schema specification. With the JSON schema vocabulary, developers can define the logical and structural rules and constraints of JSON documents. The schema can then be used to aid in processing and validation of JSON documents with libraries that are decoupled from the application, thus reducing the need for unencapsulated code to be intermixed in the application. With the JSON schema, a developer can choose JSON as the format of his data interchange and address, in a risk-mitigated fashion, the complex requirements not previously addressable with JSON alone.

The JSON schema project is a community effort, and after a decade of revisions, stands as the prevailing specification for JSON schemas. Though it is not yet a standard, the popularity of the JSON schema project indicates the level of interest for such a solution. Conceptually, the JSON schema specification resembles the XML schema, but a comparison of the two reveals differences between their models, capabilities, and semantics. For instance, though the language defines a wide range of properties to constrain the bounds of JSON value types, its numerous attributes allow for the expression of self-contradicting schema definitions.

For example, the following excerpt defines an "object" type that contains three properties: "number", "street_name", and "street_type".

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

The definition of an "object" type accepts additional constraints, one of which is "minProperties". By modifying the above "object" type definition with a "minProperties": "4", the definition becomes nonsensical, because just three properties are explicitly defined for the object.

The JSON schema has a considerably large and wide number of constraint properties, many of which are essential to effectively confine JSON documents, and many of which overlap with one another. With constraint properties that overlap in meaning, the JSON schema vocabulary presents two families of challenges:

1. It requires a higher learning curve from developers, due to the wide vocabulary and unusual or unconventional nuances in its semantics.
2. It is more difficult for validation libraries to implement, leading to solutions that implement the gray areas differently, resulting in inconsistent implementations.

The XML schema language is itself not completely free of allowing expression of self-contradicting definitions, but they are much fewer and limited. In fact, the XML schema specification was developed with close attention to both ease-of-use for developers as well as for libraries implementing the specification. Furthermore, the JSON schema project only defines the specification of the schema language, but there exist many community projects that implement this specification.

The JSON schema validator⁶ is a popular project that implements a JSON schema validator for the Java platform. By integrating this library in a Java application, the application is able to assert the conformance of all JSON documents interchanged. Other implementations of the JSON schema specification are available for a variety of platforms.

For the European Bank, let’s use the JSON schema to implement a schema for JSON messages with account identifiers.

{
  "$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": "[A-Z]{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"]
      }
    }
  }
}

This JSON schema defines the 3 object types: "swift", "iban", and "ach". It specifies regular expression patterns to assert the account information is not invalid, and declares "type" and "code" as required properties for each type, in addition to "routing" as a required property for the "ach" type. With this JSON schema, the European Bank can validate its JSON input to assert the message content is correct for every interaction.

The JSON schema brings many capabilities of XML to JSON, but it is still a work in progress. Though it is a great solution that can be used to hedge software risk, the JSON schema specification is not perfect. Due to the informal evolution of its language, the language has evolved in a direction that omits arguably important features and contains structural and logical expression patterns that are confusing and unconventional. For instance, the schema language is missing the ability to define abstract types, which can lead developers to implement convoluted workarounds that result in an associated software risk of its own.⁷

The JSON schema project has brought an invaluable wealth of contribution to the concepts behind a schema language for JSON. Despite the deficiencies in the clarity of its semantics, the JSON schema language is a versatile solution that brings many capabilities of XML to JSON.

For a closer look at the JSON schema specification, refer to Understanding JSON Schema.

JSONx

In 2014, another group started the JSONx project, which directly leverages XML to provide an equally powerful solution for JSON. The JSONx project was created specifically for the enterprise, and defines the JSON schema definition (JSD) language, which is modeled closely to the XML schema specification. Using the XML schema as its model, the JSD defines structural and logical patterns that bear a close resemblance to the XML schema definition language.

For the European Bank example, let’s use the JSD language to implement a schema for JSON messages with account identifiers.

{
  "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": "[A-Z]{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": "[A-Z]{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 }
    }
  }
}

At first glance, the JSD schema is similar in expression to the JSON schema. One difference, however, is the concise semantics of the JSD in comparison to the JSON schema. Specific to this example, the JSD places the "use": "required" property into the definition being specified, whereas the JSON schema associates this property with the parent object, requiring the name of the values to match the name of property definition. The constraint "use": "required" is only specified on the "code" property of the "swift" object and omitted from the others because "use": "required" is the default value. The JSD language was designed in close consideration of all such nuances and offers a clean and intuitive solution for the expression of JSON schemas.

From inception, a distinguishing property of the JSONx project is its primary intent to provide clarity and utility to developers. To achieve this, a powerful feature of the JSD is its convertibility to JSDx—the JSD language can be expressed in JSON files as well as XML files. Both forms are one-to-one translatable and provide developers with the ability to use advanced XML editing tools to aid in the creation of JSD documents to be live-validated and error-free.

The JSD schema from above can be expressed in the following JSDx form:

<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="[A-Z]{6}[A-Z0-9]{2}([A-Z0-9]{3})?" nullable="false" use="required"/>
  </object>
  <object name="iban">
    <property name="code" xsi:type="string" pattern="[A-Z]{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>

The JSDx form of the JSD is powerful because it provides a clear, self-validating, and risk-reduced specification for defining JSON schemas.

The JSD language is designed to address concerns of self-contradicting definitions, and relies on standard patterns for the expression of constraints. Designed in close resemblance to the XML schema definition (XSD) language, the JSD type declarations and definitions of constraints bear close resemblance to equivalent structures in XML. The JSD(x) specification provides a complete solution for the definition of structural and logical constraints, and is self-describing—providing a normative definition of the JSD(x) language expressed in the JSD(x) language itself. For a closer look at the JSD(x) specification, refer to JSON Schema Definition Language.

In addition to the JSD(x) language, the JSONx project provides reference implementations of JSD(x) processors and validators as well as a class binding API and code generator for the Java platform. With the binding API and generator, a developer can use a JSD(x) schema to auto-generate classes for the object definitions in the desired schema, which can be used to parse and marshal JSON documents that conform to the schema. The generated classes provide a strongly typed binding between the schema and the Java platform, representing the usage, constraints, and relationships specified in the schema. With strongly typed bindings to the schema, the application further reduces the software risk related to future modifications that could result in incompatibilities.

By leveraging Java’s compiler, strongly typed bindings pinpoint the incompatibilities with compile-time errors, effectively reducing the risk for bugs concerning message processing close to zero. This engineering pattern enables developers to implement changes and resolve incompatibilities quickly and confidently, not having to rely on the runtime to find bugs or failure cases—and especially not having to rely on users to stumble on the bugs themselves. The binding API is implemented with Java annotations, which allows any class to be bound to a JSD(x) schema with strong types, yet in a lightweight manner. The strongly-typed binding and code generation capabilities of JSONx support the full scope of the JSD(x) specification, designed specifically to meet the high standards for enterprise solutions.

The JSONx framework was created for enterprise solutions and offers a high standard of quality and utility for complex systems as well as ease-of-use and edit-time error validation for developers.

The JSD(x) binding engine, processor, and validator report 87% test coverage, allowing Java developers to confidently integrate the framework to bind JSD(x) schemas to their Java applications and encode, decode, and validate JSON documents. For a closer look at the JSONx framework for Java, refer to JSONx Framework for Java.

Conclusion

With a deeper look at the history of the web and software trends in recent years, we can see a close relationship between the proliferation of JavaScript and the popularity of JSON. Many articles and blog posts offer a limited perspective when comparing JSON and XML, leading readers to discount XML as obsolete, and leaving many unaware of powerful capabilities that may help them improve their software’s architecture, their software’s resilience to change, and the overall quality and stability of the software as a whole. With a deeper evaluation of the strengths and weaknesses of each standard, developers can be empowered to make better decisions for their projects.

Like the “divergence catastrophe” with HTML that led to the invention of XML, a similar effect is realized in complex codebases that rely on JSON for data interchange. The JSON specification does not encapsulate the immediate functionalities surrounding data interchange, which can lead to fragmentation of logic in the higher layers of the application. With XML, however, developers are able to push the complexity surrounding data interchange to the lower layers of the application, resulting in the ability to catch bugs earlier in the application’s lifecycle. Especially for compiled languages, in combination with a binding framework, architectures that rely on XML binding can reduce the potential for data-related error close to zero. For the enterprise, it is these powerful capabilities in the systematic reduction of software risk that make XML the “holy grail of computing.”

JSON is here to stay, and several projects are gaining momentum to offer the powerful capabilities of XML to JSON. The JSON schema project offers a community developed schema specification that has grown organically to support a wide range of attributes and declarative patterns to describe and constrain JSON documents. The JSONx project delivers an enterprise-grade schema language that is designed in close resemblance to the XML schema definition language, and offers both JSON and XML formats for the specification of JSON schema documents. With these specifications and frameworks, developers are able to reduce software risk related to higher-layer requirements surrounding data interchange, such as consumer-driven contracts, protocol versioning, content validation, and more.

The advanced features of XML were designed to mitigate the software risk related to markup languages. Use-cases with JSON are no different, and a schema language is a time-tested and proven solution to systematically hedge the wide range of software risk surrounding data interchange.

References

1. JSON vs. XML (w3schools.com, December 2016)

2. The World Wide Success That Is XML (W3C, July 2018)

3. W3C - What Is an XML Schema? (W3C, October, 2009)

4. The Internet: A Historical Encyclopedia. Chronology, Volume 3, p. 130 (ABC-CLIO, 2005)

5. JSON Schema (July 2008)

6. JSON Schema Validator (GitHub)

7. JsonSchema and SubClassing (Horne, March 2016)