Free White Papers
Ask the experts
Got a question? Put us to the test
Is there an alternative to XML?
Print | Email | Digg this story!
In this article we assess Java Script Object Notation (JSON) as a workable alternative to eXtensible Mark-up Language (XML) for developing interfaces between systems.
XML is simple, hierarchical, platform-independent and human-readable. It’s also bloatware that makes loading a large document into memory slow and therefore time-expensive. XML requires a parser and program logic to read in pre-defined, agreed tags and assign them to variables in the code.
JSON - a Light Alternative to XML
This is where the lightweight snappy alternative JSON comes in. Whilst it appears similar to XML with field names and values appearing in a hierarchical text-based structure, the concept is much closer to the serialization of a complex object, common to true Object-Oriented languages.
For example, from Java it is possible to save a complex memory object (containing a mixture of simple data types, but not binary) as a JSON data file. It is then possible to subsequently load a JSON data file back in so that the object, structure and data is reconstructed in memory without any mapping routine.
The decision as to when to use either JSON or XML is not straight forward however.
Most solutions should rightly continue to use XML, employing the power of complex types, attributes, validation schemas and support for binaries (encoded), all of which JSON doesn’t offer.
On the other hand, if you have a Java application talking only to other Java systems, and speed and simplicity is required, JSON would save you both in development and execution time.
The table below summarizes the main differences between XML and JSON:
Comparison of XML and JSON
| Acronym: XML | Acronym: JSON |
| Name: Extensible Markup Language | Name: Java Script Object Notation |
| Description: To facilitate the sharing of data across different information systems, particularly over the Internet, in a human-readable, self-describing form. | Description: A lightweight human-readable data interchange format, supported by Java. |
| Developed by: World Wide Web Consortium (W3C) | Developed by: Douglas Crockford |
| Subset of: Standard Generalized Mark-up Language | Subset of: Object Literal Notation |
| Frequently produced by: databases and used as a neutral interchange standard over the web | Frequently produced by: serialization of objects from Java |
| Aimed at language(s): No specific language | Aimed at language(s): Java, Python, but methods available for other languages. |
| Aimed at platform(s): Any – platform independent | Aimed at platform(s): Any – platform independent |
| MIME type: application/xml | MIME type: application/json |
Basic types: (large data type hierarchy)
| Basic types:
|
Example: <?xml version=”1.0”?> <rootTag> <firstName>John</firstName> <lastName>Smith</lastName> <address> <city>New York, NY</city> <zipCode>10021</zipCode> <streetAddress>21 2nd street</streetAddress> </address> <phoneNumbers>212 732-1234</phoneNumbers> <phoneNumbers>646 123-4567</phoneNumbers> </rootTag> | Example: { "firstName": "John", "lastName": "Smith", "address": { "city": "New York, NY", "zipCode": 10021, "streetAddress": "21 2nd Street" }, "phoneNumbers": [ "212 732-1234", "646 123-4567" ] } |
| Bytes in above example: 320 | Bytes in above example: 263 |
| Provision for binary data: CDATA section with MIME/BASE64 encoding, etc. | Provision for binary data: None specifically – but could be held by a string. |
| Recursive / nested: Yes | Recursive / nested: Yes |
| Versioned: Yes | Versioned: No |
| Accompanying files: Document Type Definition (DTD) or Schema (XSD), Stylesheets (XSL) | Accompanying files: None. |
| Extensions: XPath, XQuery, XML Namespaces, XML Signature, XML Encryption, XPointer | Extensions: None. |
| Load method supported: XML Dom Load, parse and interrogate (lots of code!) | Load method supported: var p = eval("(" + JSON_text + ")"); |
| Issues / problems: Size / verbosity, and complexity. | Issues / problems: Security – when a serialized object is evaluated; and cross-site forgery. |
| Primary use: Expressing described, structured, human-readable data using complex markup. | Primary use: As a Java serialized object file format, also human readable. |
| Superseded by: XML implementations are still XML! | Superseded by: YAML – Addresses some of the limitations of JSON, but is still simpler than XML. |
Pros Attributes No security risks Many extensions ‘Binary’ data support Many datatypes Cons Large / bloatware Needs large Object Model to be loaded Slow access to tags, values and attributes
| Pros Lightweight Can be instantiated directly as an object Loaded very quickly Cons No attributes Comes with security risks if indiscriminately instantiated No binary data support Few datatypes Delimiting characters can make for tricky human reading
|
Conclusion
JSON is ideally suited to environments where Java (or languages with similar support for JSON) is the only language used and where there is a speed requirement. JSON is the format of choice for loading & saving (serializing & deserializing) of objects/records to and from Java applications, where all fields can be broken down to primitive data types. This makes it quick and practical within large complex computing environment, but where communication interfaces with external (or non-Java) systems are concerned, it makes sense to continue using XML.
If you have any questions about the subjects covered in this white paper or you would like to find out more about how Oakleigh Consulting could help your organisation, please contact us on 0161 835 4100 or email us.
Copyright
You may publish, quote or reproduce any white papers on this website on the condition that Oakleigh Consulting Ltd is notified, properly credited (and linked to) as the source, including our URL: www.oakleigh.co.uk.