Grey Background for JSON vs XML in RPG

JSON vs XML, Part 3: 12 Differences

Which one is right for me?

JSON vs XML: when did these data formats originate, and how are they used in RPG (and development in general)? Both have a tremendous history behind them and are either derived from, inspired by, or parent to a variety of other means to hold data. This article will draw a few mentions to content mentioned in our previous blog posts on REST[1] vs SOAP[2] APIs (and a comparison[3]). This third in a series of three articles pits JSON versus XML, and compares the benefits of each of them. The first article[4] details XML’s history, and the second one looks into JSON[5]. Before getting too deep into the weeds, let’s define a few important words mentioned in this series.

Definitions

The realm of client-server communication is loaded with acronyms and terms to keep track of. This section elaborates upon a few key terms:

  1. XML – Extensible Markup Language – XML is a widely used data format, similarly structured to HTML. XML can be used in both SOAP and REST API calls.
  2. JSON – JavaScript Object Notation – JSON is arguably the fastest-growing data format used when communicating over HTTP in the present day, thanks to its memory-efficient format.
  3. WSDL – Web Service Definition Language – WSDL is an XML-based notation used for describing functionality of a SOAP-based web service[6]. WSDL is used at development time to describe a web service program with procedure names, input/output parameters, the URL of the web service, and the enveloping mechanisms and transport to be used (i.e., SOAP over HTTP).
  4. XSD – XML Schema Definition – An XSD is a file type that describes the structure of an XML document.
  5. REST – Representational State Transfer – REST is an architectural style, rather than a protocol (protocols define how diverse modules interact, while styles define how sets of protocols are organized[7]). REST utilizes existing web protocols and tools to communicate with APIs.
  6. SOAP – Simple Object Access Protocol – SOAP is a data-centric protocol that uses WSDL files for client-consumer communication.
  7. RPG – RPG is the primary language used when developing business applications on the IBM i OS. Also known as RPG Free, RPGLE, and RPG IV.
  8. IBM i – IBM i is the operating system used on IBM’s POWER servers. IBM i is the OS name, which was formerly i5/OS and OS/400. AS/400 is what was renamed to iSeries, System i, and then IBM Power Systems.

Table of Contents

JSON vs XML Comparison

12 Differences

JSON vs. XML – the two data formats are everywhere. Each one has unique strengths and weaknesses, with JSON being the preferred format for most data interchange across REST APIs; XML certainly still has its place.

JSON XML
1
Released in 2001
Released in 1996
2
More concise
More verbose
3
Easier to read
More complex
4
More lightweight
More text-heavy
5
For data interchange
Markup language / document-

oriented
6
Used with REST
Used with SOAP & REST
7
Includes strict data types
Lacks strict data types
8
Explicit Array / Object support
No such support
9
Does not support schemas for

strict validation
Supports schemas for strict

validation
10
Doesn't require extensibility
More extensible
11
Supports only UTF-8 and UTF-16
Supports multiple encoding standards
12
No comment support
Supports comments

1. Since its inception in 2001, JSON took about 10-15 years to surpass XML in popularity. XML itself was released in 1996.[8]

2. JSON is much more concise (or sparing the use of excess words) than XML. This is abundantly clear when viewing two comparisons of these formats. For example, an XML statement like this…

				
					<Parent>
	<Child1>Alex</Child1>
	<Child2>Belle</Child2>
	<Child3>Charles</Child3>
</Parent>
				
			

… can be expressed analogously through JSON like this…

				
					{
	"Parent": {
		"Child1": "Alex",
		"Child2": "Belle",
		"Child3": "Charles"
	}
}
				
			

Excluding white-spacing and indentation (i.e. “minifying” the code), the XML totals at 84 characters, while JSON accomplishes the same at 64 characters.

3. Similar to the previous example, JSON’s brevity also makes it easier to read. This is because every key in JSON is represented only once for a given value or object/array, while XML’s markup format means every element is represented twice (in the opening and closing tags).

4. A third beneficial aspect of JSON’s condensed nature is that it makes transported data lightweight. Fewer characters in calls translates to fewer bytes of information passed around.

5. JSON vs XML: each have different design philosophies when it comes to determining their strengths in how they interchange data. JSON is much more of a data-centered format than XML, which is more document-oriented.[9] Document-oriented formats tend to rely on metadata – data about the data. For example, HTML relies on metadata contained in attributes and tags to determine how to transform and display the web page based on a linked stylesheet. XML does not contain display information within the document (generally this is found within an XSLT document instead), but it does make use of metadata in the form of attributes, tag names, namespaces, and even the hierarchical structure of the overall document to give additional context to the data contained within. JSON does not make use of similar metadata for the most part except that it does have somewhat of a hierarchical structure with regards to nested objects and arrays. There are no attributes in JSON; where one might have used attributes on an element in XML one might instead choose to create a child object in JSON to contain those values as separate key/value pairs that are still linked together in one single parent.

6. It’s no surprise that different data formats may be more tightly associated with different modes of HTTP interchange. For example, both JSON and XML can be used with REST APIs, but not SOAP. JSON is a stateful (state-aware) protocol, and is data format-independent – it is a very flexible protocol. SOAP as a standard was first described when XML was the most widely used data format, and so XML is the only accepted data format for SOAP. SOAP relies on strict formatting for header elements and tags within the document, and so the use of XSDs and WSDLs available only with XML is common – this kind of strict validation is not available with JSON. Additionally, all SOAP requests are POST requests, and are stateless – it is not a stateful protocol like REST.

7. One major difference when comparing JSON vs. XML is that JSON data includes strict data types (string, number, boolean null). XML does not natively define data types, although XSDs allow for some definition of what data is expected in a given field.

8. JSON has explicit data types to represent a single object – a parent element that contains one or more child tags – or an array – a collection of tags. Both data types have specific notation to demarcate the beginning and end of the object/array within the document. In XML, what would be equivalent to a JSON object type is just an element that, instead of containing data, contains only other elements. The XML equivalent of an array is accomplished by repeating the desired element (generally within a containing parent element). The parent elements of the “object” or “array” are notated the same as any other element in the document – there is no specific demarcation. If your XML document is not displayed with indentation, it can be difficult to determine when you have reached the end of a parent element.

9. Schema documents – known as XSDs – are used to provide element and attribute definitions and validation for XML documents. They can be used to define custom field types that can be referenced using namespaces within XML documents.[10] JSON does not have an equivalent to XSDs or namespaces – it instead relies on its native data types, and the community generally uses external tools (like OpenAPI) to define and document their APIs.

10. Extensibility is the means by which a given software system or format can be enhanced beyond its base capabilities without major rewriting of code or alteration of its basic architecture [11]. Extensibility is accomplished in XML by the use of user-defined tags, and further expanded by use of XSDs for additional definition of field types and validation. However, JSON is not considered to be extensible because, by design, it does not require extensibility [12] since it is flexible enough and is not restricted by the markup language format.

11. JSON simplifies encoding by only allowing for UTF-8, UTF-16, and UTF-32 encoding. [13] XML can accept a variety of encoding formats, increasing its versatility and adding complexity. For example, these are valid examples of how an XML document might be encoded [14]:

				
					<?xml version="1.0" encoding="windows-1252"?>
 
<?xml version="1.0" encoding="ISO-8859-1"?>

				
			

12. As it is designed to be a lightweight and flexible data-interchange format, JSON does not allow for commenting. As stated by Douglas Crawford (who wrote JSON’s specifications), “I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability.” [15] XML documents allow for comments using the form:

				
					<!-- text -->
				
			

Summary

Modern development is trending towards REST and JSON due to their flexibility and overall approachability, but XML has not lost its place. While the concise nature of JSON might make for a smaller payload, some applications still require the strict validation that only an XSD and an XML document can offer, and so they stick with a SOAP service. As developers, we also know that sometimes it comes down to how someone 20 years ago wanted to store the data, and momentum from that decision is driving your work today. Regardless, we’re here to help.

Try RXS free for 30 Days

You can use RXS to create / parse both JSON and XML in RPG, and to offer and call both REST and SOAP web services. If your business has a use case in mind, reach out to us for a free proof of concept.

A proof of concept gives you access to all of RPG-XML Suite’s capabilities in the form of a customized demonstration. For example, if your business needs to create data, send it to an API, and parse the result, our team can create a program which accomplishes all of those tasks for you at no cost. 

Think of it like this: with a free trial or demonstration of a program, you only get a view of what a piece of software can accomplish. With a proof of concept however, you get a springboard for new development – it is our goal that the proof of concept both demonstrates the utility of RXS and acts as a customized reference for you for further development.

A proof of concept is completely free, with no commitment required.

References