top button
Flag Notify
    Connect to us
      Facebook Login
      Site Registration Why to Join

    Get Free Article Updates

Facebook Login
Site Registration

JSON vs. XML

0 votes
109 views

                                                                                                                                     

JSON vs. XML

Both JSON and XML are capable of representing in-memory data in a readable textual format. Similarly, both of them are isomorphic, which means an equivalent one of the given piece of text is possible in the other format. For instance, while invoking a public Web service, a developer can state in the query string parameter whether the output should be in XML or JSON format.

Due to such similarities, it might not be simple to choose a suitable data exchange format from the two. This is where it is essential to consider the differentiating characteristics or both the formats and find out which one is more suitable for a particular application.

Compares the major characteristics of both formats.

Characteristic

JSON

XML

Data Types

Offers scalar data types and articulates structured data in the form of objects and arrays

  Does not offer any idea of data types due to which relying on XML Schema is essential for specifying information about the data types.

Array Support

Provides native support

  Expresses array by conventions. For instance, XML employs an outer placeholder element that forms the content in an array as inner elements.

Object Support

Provides native support

  Expresses objects by conventions, usually by combining attributes and elements.

Null Support

Recognizes the value natively.

  Mandates the use of xsi:nil on elements in an instance document along with the import of the related namespace.

Comments

Does not support

  Provides native support (via APIs).

Namespaces

Does not support namespaces and that naming collisions do not occur, as objects are nested or the object member name has a prefix.

  Accepts namespaces to prevent name collisions and safely extent the prevalent XML standards.

Formatting

Is simple and offers more direct data mapping

  It complex and needs more effort for mapping application types to elements.

Size

Has very short syntax, which gives formatted text wherein most space is taken up by the represented data.

  Has lengthy documents, particularly in case of element-centric formatting.

Parsing in JavaScript

Has very short syntax, which gives formatted text wherein most space is taken up by the represented data.

  Has lengthy documents, particularly in case of element-centric formatting.

Parsing in JavaScript

Needs no additional application for parsing (JavaScript’s eval() function work well ).

  Implements XML DOM and requires extra code for mapping text to JavaScript objects.

Parsing

Has JSONPath for selecting specific sections of the data structure but is not widely used.

  Has XPath specification for doing the same in an XML document and is widely used.

 

Learning Curve

Is not sleep at all, due to familiarity with the structure and the underlying dynamic programming language.

  Is steep with the need to know several technologies and concepts such as XPath, XSL Transformations (XSLT), DOM, Schema, and Namespaces.

Complexity

Is complex

  Is more complex.

Schema (Metadata)

Has a schema but is not widely used.

  Used many specifications    for defining a schema,        including XML Schema      Definition (XSD) and Document Type Definition (DTD)

Styling

Has no special specification.

  Has XSLT specification for  styling an XML document.

Security

Is less secure, as the browser has no JSON parser.

  Is more secure.

posted Feb 10, 2018 by Gn Guruswamy

  Promote This Article
Facebook Share Button Twitter Share Button LinkedIn Share Button


Related Articles

Comparison of JSON with Relational Databases

Although even JSON hosts or represents data, it differs significantly from the conventional relational database model implemented in RDBMS applications such as SQL Server and MySQL. Knowing these differences can help you to prefer JSON over RDBMS or vice-versa, as  per the data structure and type.

Following are the basic differences:.

  • Structure: A table stores data in a relational database, while JSON uses arrays and objects from the same, which can be recursively nested.
  • Metadata: A schema stores data about the type as well as structure of the stored data in a relational database. Further, schemas are created while creating a database and tables, not at the time of storing data. Even JSON can use a schema but it is not pre-created like in a relational database. Usually, a JSON structure is self-describing but if it uses a schema, it ensures more flexibility than a schema in a relational in a relational atabase.
  • Data Retrieval:  A relational database utilizes SQL, which is a robust and expressive language based on relational algebra, for obtaining data from tables . On the other hand, JSON does not use any popular language. In fact, it uses JSON Query Language (JAQL) and JSONiq, which are still evolving query languages.
  • Sorting: In a relational database, SQL easily helps in retrieving data and displaying it in ascending or descending order. In JSON, a developer can sort arrays.
  • Learning Curve: JSON has a much smooth learning curve. This is because the data types and structure supported here are used in several programming languages. Therefore, a developer with basic programming background grasps JSON concepts and coding quite fast. On the other hand, RDBMS is  a distinct field to learn and explore, which takes time to master. However, once mastered, it has its own opportunities and benefits to offer.
  • Application: The market has several commercial as well as open source relational databases to offer. There are also NoSQL databases but they use JSON to store data. JSON is usually implemented in several programming languages.
READ MORE
Contact Us
+91 9880187415
sales@queryhome.net
support@queryhome.net
#280, 3rd floor, 5th Main
6th Sector, HSR Layout
Bangalore-560102
Karnataka INDIA.
QUERY HOME
...