Data Parsing
And
Conversion Between XML/JSON
Developed by
Wajiha Itikhar
Reg. # 1993-FBAS/BSCS/F10
Rida Kamal
Reg. # 2064-FBAS/BSCS/F10
Supervised by
Ms. Asma Batool
Department of Computer Science &Software Engineering
International Islamic University Islamabad
2014
Dissertation
Dissertation
A dissertation submitted to the
Department of Computer Science and
Software Engineering,
International Islamic University, Islamabad
as a partial fulfillment of the requirements
for the award of the degree of
BS of Computer Science
Conversion Between XML/JSON
Page |i
Dedication
Dedication
To Allah Almighty who gave our strength to complete this project.
also to our parents and our supervisor for her countless support and
help.
Conversion Between XML/JSON
P a g e | ii
Declaration
Declaration
We hereby declare that this Software, neither as a whole nor as a part therefore has been
copied out from any source. It is further declared that we have developed this Software
entirely on the basis of our personal efforts made under the sincere guidance of our
teachers and supervisor. No portion of the work presented in this report has been
submitted in support of any application for any other degree or qualification of this or any
other university or institute of learning.
Wajiha
Iftikhar
1993-FBAS-BSCS-F10
Signed ……………….
Rida Kamal
2064-FBAS-BSCS-F10
Signed………………
Conversion Between XML/JSON
P a g e | iii
Acknowledgement
Acknowledgement
Praise to the name of Allah Almighty, the most compassionate and merciful, without His
help and blessings, we will never be able to accomplish this project successfully . To me
the blessing of Allah and true teachings of the last Prophet Mohammad (S.A.W) means to
above all.
We want to thank all those people who helped us in our project. Without their
contribution we will never be able to complete it on time. Our families also encouraged us
a lot in completing the project. No doubt without all these people we would never be able
to complete our task in a short time.
We express sincere gratitude to Ms. Asma Batool, Lecturer/ Acting chairperson , IIU for
her great help. Her advice, support, constructive criticism and personal interest during this
project has steered us in the right direction and helped us a great deal in completing the
project.
We are also grateful to our beloved friends, who have been there for us in joys, in
sorrows, in hardships and in delights. We hope the report is informative to anyone who
refers it.
Thanking all our evaluators and reader(s).
Wajiha Iftikhar
1993-FBAS-BSCS-F10
Rida Kamal
2064-FBAS-BSCS-F10
Conversion Between XML/JSON
P a g e | iv
Project in Brief
PROJECT IN BRIEF
Software Name
Tomcat
Project Title
Data Parsing
And
Conversion Between XML/JSON
Undertaken By
Wajiha Iftikhar and Rida Kamal
Supervised By
Asma Batool
Tools Used
Java,XML-5
Operating System
Windows 8
System Used
Core-I3, Ram 4GB
Installed Memory
4GB
Languages
JAVA SCRIPT AND JAVA
Starting Date
01-08-2014
Completion Date
1-01-2015
Conversion Between XML/JSON
Page |v
Abstract
ABSTRACT
JSON and XML are seen by some as competing markup formats for content
and data. JSON has become predominant in the mobile and browser domains
while XML dominates the Server, Enterprise and Document domains. Where
these domains meet and need to exchange information there is pressure for one
domain to impose on the other their markup format.
Data Parsin And Conversion Between XML/JSON is an architecture that
addresses this problem by providing for high quality bidirectional
transformations between XML and JSON. Previous approaches provide for
only a single mapping intended to cover all cases, but generally cover few cases
well. Data Parsin And Conversion Between XML/JSON uses Schema and
annotations to allow highly customizable transformations that can be tuned for
individual schemas, elements, attributes and types yet still be easily configured.
Conversion Between XML/JSON
P a g e | vi
List of figures
Table of Contents
Chapters
1
Page No
Introduction........................................................................................................... 1
1.1 Client Server Model ................................................................................................. 1
1.2 Apache Tomcat ...................................................... Error! Bookmark not defined.
1.3 Problem Statement ................................................................................................... 2
1.4 Proposed Solution .................................................................................................... 3
1.5 Scope ........................................................................................................................ 3
1.6 methadology used ..................................................................................................... 3
1.7 System Overview ..................................................................................................... 4
1.8 report outline ............................................................................................................ 5
2
Literature Review ....................................................................................................... 7
2.1 XML ......................................................................................................................... 7
2.1.1 History ................................................................................................................ 7
2.1.2 xml ...................................................................................................................... 7
2.1.3 Applications of XML.......................................................................................... 8
2.1.4 Key terminology ................................................................................................ 8
2.2 JSON ...................................................................................................................... 10
2.2.1 History………………………………………………………………………...10
2.2.2 Data types, syntax and examles..……………………………………………...11
2.2.3 Using Json in JavaScript.……………………………………………………...12
2.2.4 Applications…………………………………………………………………...13
2.2.4.1 JSON-RPC.……………………………………………………………...13
2.2.4.2 Ajax……………………………………………………………………...13
2.2.5 Security issues.………………………………………………………………...13
2.3 Comparison between XML and JSON .................................................................. 14
2.3.1 Similarities...…………………………………………………………………...15
Conversion Between XML/JSON
Page |x
List of figures
2.3.2 Differences..…………………………………………………………………...15
2.4 Result…….………………………………………………………………………...15
2.4.1 Scenario……………………………………………………………………...16
3
System Analysis......................................................................................................... 22
3.1 Proposed System .................................................................................................... 22
3.2 Functional Requirements........................................................................................ 23
3.2.1 XML to JSON .................................................................................................. 23
3.2.2
JSON to XML................................................................................................. 24
3.2.3
XML/JSON to JSON tree ............................................................................... 24
3.3 Non-Functional Requirements ............................................................................... 24
4
3.3.1
Usability......................................................................................................... 24
3.3.2
Reliability ...................................................................................................... 24
3.3.3
Availability .................................................................................................... 24
3.3.4
Decision making ............................................................................................ 24
3.3.5
Availability .................................................................................................... 24
System Design ........................................................................................................... 26
4.1
System Overview .................................................................................................. 26
4.2 Detailed Diagram of XML/JSON Conversion ....................................................... 27
4.3
System Usecase ..................................................................................................... 29
4.3.1 Run ................................................................................................................... 29
4.3.2 Web Browser ................................................................................................... 30
4.3.3 Bidirectional Conversion ................................................................................. 30
4.4 Sequence Diagram ................................................................................................ 30
5
Implementation ......................................................................................................... 33
5.1
Tools and Technologies ...................................................................................... 33
5.1.1
Eclipse...………..…………………………………..……………...............33
5.1.1.1
Mylyn ................................................................................................... 33
Conversion Between XML/JSON
P a g e | xi
List of figures
5.1.1.2
software updates……………………………………………………...34
5.1.1.3
Enterprise Java Tooling….…………………………………………...34
5.1.1.4
Model Driven development…………………………………………...35
5.1.1.5
The smaller features…...……………………………………………...35
5.1.2
Java language………...……………………………………………………...36
5.1.3 Tomcat Framework…...……………………………………………………...36
5.2
6
Proposed Algorithm ............................................................................................... 38
5.2.1
A Pragmatic approach .................................................................................. 38
5.2.2
Preserving order ........................................................................................... 39
5.2.3
Semi-Structured XML…………………………………………………….40
5.2.4
Examples:..................................................................................................... 41
5.2.5
XML/JSON to JSON tree ............................................................................ 43
5.2.6
Algorithm Disease Diagnose: ...................... Error! Bookmark not defined.
Testing........................................................................................................................ 47
6.1
Software testing Strategies .................................................................................. 47
6.1.1
White-Box testing ........................................................................................ 47
6.1.2
Black-Box testing......................................................................................... 47
6.1.3
Visual testing ............................................................................................... 48
6.1.4
Testing of XML/JSON conversion .............................................................. 48
6.1.5
Test Case ...................................................................................................... 48
6.1.5.1 Load
page……………………………………………………………...Error! Bookmark not
defined.
6.1.5.2
XML to JSON conversion Test Page…...……………………………...51
6.1.6.3 JSON to XML conversion Test Page ..................................................... 52
6.1.5.4
JSON/XML to JSON tree conversion Test Page ……...…..…………...54
6.1.6 Results….…………………………………………. ……………..…………...54
Conversion Between XML/JSON
P a g e | xii
List of figures
7
Conclusion and Outlook ........................................................................................... 63
7.1 Achievements and Improvements .......................................................................... 63
7.2 Future Recommendations....................................................................................... 63
7.3 Summary ................................................................................................................ 64
Appendices
Appendix A.............................................................................................................................67
Appendix B……………………………………………………………………......….69
Conversion Between XML/JSON
P a g e | xiii
List of figures
List of figures
Figure 1-1: System Overview .............................................................................................. 4
Figure 3-1: Our system’s architecture for conversion ....................................................... 23
Figure 4-1 System overview 1 ........................................................................................... 26
Figure 4-2 System overview 2 ........................................................................................... 27
Figure 4-3 Detailed Diagram of System ............................................................................ 28
Figure 4-4 Use Case 1 ........................................................................................................ 29
Figure 4-5 Use Case 1 ........................................................................................................ 29
Figure 4-6 Use Case 1 ........................................................................................................ 30
Figure 4-7 Bidirectional Conversion ................................................................................. 30
Figure 4-8 system use case ................................................................................................ 32
Figure 5-1 Diagram editor………………………………………………………………..35
Conversion Between XML/JSON
P a g e | xiv
List of Tables
List of Tables
Table 2-1 Scenario 1 Json vs. XML Timings .................................................................... 16
Table 2-2 Scenario 1 JSON vs. XML CPU/Mem .............................................................. 16
Table 2-3 Scenario 2 JSON vs. XML Timings .................................................................. 17
Table 2-4 Scenario 2 JSON vs. XMLCPU/Mem ............................................................... 18
Table 5-1 Apache Tomcate version ................................................................................... 37
Table 0-1 Load Page Test Case ......................................................................................... 49
Table 0-2 Load page Test Case.......................................................................................... 50
Table 0-3 XML to JSON conversion test case................................................................... 51
Table 0-4 JSON to XML conversion Test case ................................................................. 52
Table 0-4 JSON/XML conversion to tree Test case .......................................................... 54
Conversion Between XML/JSON
P a g e | xi
CHAPTER # 1
Chapter # 1
Introduction
Introduction
XML stands for EXtensible Markup Language. XML is a markup language much
like HTML. XML was designed to describe data, not to display data .XML tags
are not predefined. We have to define our own tags. XML is designed to be selfdescriptive.
JSON is an open, text-based data exchange format . Like XML, it is humanreadable, platform independent, and enjoys a wide availability of
implementations. Data formatted according to the JSON standard is lightweight
and can be parsed by JavaScript implementations with incredible ease, making it
an ideal data exchange format for Ajax web applications. Since it is primarily a
data format, JSON is not limited to just Ajax web applications, and can be used in
virtually any scenario where applications need to exchange or store structured
information as text.
Data parsing and conversion between XML/JSON is both a design architecture
and a reference implementation of a tool for JSON/XML transformations. Unlike
other XML/JSON transformation architectures and tools, Data parsing and
conversion between XML/JSON attempts to fulfill the needs of both XML and
JSON authors and developers equally. Data parsing and conversion between
XML/JSON provides the ability to easily describe both unidirectional and
bidirectional XML/JSON transformations that produce markup which authors of
that particular format would like to use.
This web based application for data translation, will work as user’s assistant in
coding and programming. User will not have to bother about writing code in either
xml or Jason. When user is working on Jason and he gets some help code in xml
from any site, he does not have to waste his time in writing that code in to Jason.
He can simply use this app and get his desired result. It has two panels.Code
editor on left and tree editor on right. There will be a splitter between the two
panels that allows changing the width of both panel. If user enters an input in one
panel, the corresponding output will be generated in the panel. Tree editor
displays Json data in editable tree. It makes easy to create , duplicate, remove field
and to edit the contents of the field.
As our project is real client project we get project from elixir software technology
park so they required bidirectional conversion and tree of json explanation which
show all attributes etc.
Client Server Model
The client–server model of computing is a distributed application structure that
partitions tasks or workloads between the providers of a resource or service,
called servers, and service requesters, called clients. Often clients and servers
communicate over a computer network on separate hardware, but both client and
server may reside in the same system. A server host runs one or more server
Conversion between XML/JSON
Page | 1
Chapter # 1
Introduction
programs which share their resources with clients. A client does not share any of its
resources, but requests a server's content or service function. Clients therefore
initiate communication sessions with servers which await incoming requests.
Apache Tomcat
Apache Tomcat (or simply Tomcat, form erly also Jakarta Tomcat) is an open
source web server and servlet container developed
Foundation (ASF).
Tomcat
implements
by the Apache
several Java
Software
EE specifications
includingJava Servlet, JavaServer Pages (JSP), Java EL, and WebSocket, and
provides a "pure Java" HTTP web serverenvironment for Java code to run in.
Apache is developed and maintained by an open community of developers under the
auspices of the Apache Software Foundation, released under the Apache
License 2.0 license, and is open-source software.
1.3 Problem Statement
Favor XML over JSON
1. It is text-based.
2. Easy to take XML and apply XSLT to make XHTML
3. XML is supported by many more desktop applications than JSON.
4. JSON can be put in the XML on the way back to the client – the benefit of both! It’s
called XJAX (stands for X-domain JavaScript And XML).
5. Simply, AJAX includes XML in it and not JSON.
6. It is position-independent.
Favor JSON over XML
1. JSON requires less tags than XML – XML items must be wrapped in open and close
tags whereas JSON we just name the tag once
2. Because JSON is transportation-independent, we can just bypass the XMLHttpRequest
object for getting our data.
Conversion between XML/JSON
Page | 2
Chapter # 1
Introduction
3. JavaScript is not just data – we can also put methods and all sorts of goodies in JSON
format.
4. Jason is simpler, easier to read ,smaller, lighter weight, more human readable, and
generally faster than XML
5. We can get JSON data from anywhere, not just our own domain.
6. JSON is well suited to data interchange.
Both languages have their own significance subject to the need of client. User
sometimes could need xml data format and sometimes Json. If user (a programmer) is
working on a very high level project and he need to search for already built sample
code to save his time and he finds that particular module in xml format. But what he
requires is json. So he does not need to convert that xml code into JSON manually. He
will just import his xml data into this app and with a single click he‘ll get his desired
result.
Proposed Solution
Client server application will b developed which facilitate the customer to conver XML/JSON and
JSON/XML.
1.5 Scope

The new system will help user to generate his required output within no time..

It’ll provide the user with ease of auto conversion between two format.. So user just
opens a file and can convert it in to its alternative format.

It is a real client project
1.6 METHODOLOGY USED

Html5 is used to develop a converter. The converter converts the XML to JSON and then
Json is shown in tree mode.
Conversion between XML/JSON
Page | 3
Chapter # 1

Introduction
By clicking on browse or open button the xml file can be located on system and after
selecting the file it can be imported in to the editor.

Back on the web page and with the selected xml file, after clicking the button “convert”,
it will convert the xml data into json. And vice versa

By choosing the save option in main menu , it can be saved again on the system.

Json file is now ready to be used.
1.7 System Overview
XML/JSON CONVERTOR
Figure 0-1: System Overview
Json Tree Overview
Conversion between XML/JSON
Page | 4
Chapter # 1
Introduction
1.8 Report Outline
 This report covers in detail all the aspects of the system. For the sake of
understanding and clarity, this report has been divided into seven different
chapters:
 The Introduction chapter explains the system, the need of the system, Scope of the
system, its objective and system overview.
 The literature Review presents the related work and its comparison with our
technique.
 The System Analysis specifies the functional and non functional requirements of
the system.
 The System Design focuses on the design of the system architecture.
 The Implementation section defines the coding standards followed in the project.
 The testing section addresses the different kind of testing performed on our system
and prepares a report of our testing and the last section concludes the system and
specifies the future directions and recommendations.
Conversion between XML/JSON
Page | 5
CHAPTER # 2
Chapter # 2
Literature Review
Literature Review
2.1 XML
2.1.1History
XML is an application profile of SGML .
The versatility of SGML for dynamic information display was understood by early digital
media publishers in the late 1980s prior to the rise of the Internet. By the mid-1990s some
practitioners of SGML had gained experience with the then-new World Wide Web, and
believed that SGML offered solutions to some of the problems the Web was likely to face
as it grew. Dan Connolly added SGML to the list of W3C's activities when he joined the
staff in 1995; work began in mid-1996 when Sun Microsystems engineer Jon
Bosak developed a charter and recruited collaborators. Bosak was well connected in the
small community of people who had experience both in SGML and the Web.
XML was compiled by a working group of eleven members, supported by a (roughly)
150-member Interest Group. Technical debate took place on the Interest Group mailing
list and issues were resolved by consensus or, when that failed, majority vote of the
Working Group. A record of design decisions and their rationales was compiled
by Michael Sperberg-McQueen on December 4, 1997. James Clark served as Technical
Lead of the Working Group, notably contributing the empty-element "<empty />" syntax
and the name "XML". Other names that had been put forward for consideration included
"MAGMA" (Minimal Architecture for Generalized Markup Applications), "SLIM"
(Structured Language for Internet Markup) and "MGML" (Minimal Generalized Markup
Language). The co-editors of the specification were originally Tim Bray and Michael
Sperberg-McQueen. Halfway through the project Bray accepted a consulting engagement
with Netscape, provoking vociferous protests from Microsoft. Bray was temporarily
asked to resign the editorship. This led to intense dispute in the Working Group,
eventually solved by the appointment of Microsoft's Jean Paoli as a third co-editor.
The XML Working Group never met face-to-face; the design was accomplished using a
combination of email and weekly teleconferences. The major design decision ns were
reached in a short burst of intense work between August and November 1996, when the
first Working Draft of an XML specification was published. Further design work
continued through 1997, and XML 1.0 became a W3C Recommendation on February 10,
1998.
2.1.2 XML
Extensible Markup Language (XML) is a markup language that defines a
set of rules for encoding documents in a format which is both humanreadable and machine-readable. It is defined by the W3C's XML 1.0 Specification and by
several other related specifications, all of which are free open standards.
Conversion between XML/JSON
Page |7
Chapter # 2
Literature Review
The design goals of XML emphasize simplicity, generality and usability across
the Internet. It is a textual data format with strong support viaUnicode for different human
languages. Altho ugh the design of XML focuses on documents, it is widely used for the
representation of arbitrarydata structures such as those used in web services.
Several schema systems exist to aid in the definition of XML-based languages, while
many application programming interfaces (APIs) have been developed to aid the
processing of XML data.
<person firstName="John" lastName="Smith">
<address street="21 2nd Street" city="New York" state="NY" zip="10021"
/>
<phoneNumber type="home" number="212 555-1234" />
<phoneNumber type="fax" number="646 555-4567" />
</person>
2.1.3 APPLICATIONS OF XML
As of 2009, hundreds of document formats using XML syntax have
been developed, including RSS, Atom, SOAP, and XHTML. XML-based formats have
become the default for many office-productivity tools, including Microsoft Office (Office
Open XML), OpenOffice.org and LibreOffice (OpenDocument), and Apple's iWork.
XML has also been employed as the base language for communication protocols, such
as XMPP. Applications for the Microsoft .NET Framework use XML files for
configuration. Apple has an implementation of a registry based on XML.
XML has come into common use for the interchange of data over the Internet. IETF RFC
7303 gives rules for the construction of Internet Media Types for use when sending XML.
It also defines the media types application/xml and text/xml, which say only that the data
are in XML, and nothing about its semantics. The use of text/xml has been criticized as a
potential source of encoding problems and it has been suggested that it should be
deprecated.
RFC 7303 also recommends that XML-based languages be given media types ending
in +xml; for example image/svg+xml for SVG.
2.1.4 KEY TERMINOLOGY
The material in this section is based on the XML Specification. This is not an
exhaustive list of all the constructs that appear in XML; it provides an introduction to the
key constructs most often encountered in day-to-day use.
(Unicode) character
By definition, an XML document is a string of characters. Almost every
legal Unicode character may appear in an XML document.
Processor and application
The processor analyzes the markup and passes structured information to
an application. The specification places requirements on what an XML processor
Conversion between XML/JSON
Page |8
Chapter # 2
Literature Review
must do and not do, but the application is outside its scope. The processor (as the
specification calls it) is often referred to colloquially as an XML parser.
Markup and content
The
characters
making
up
an
XML
document
are
divided
into markup and content, which may be distinguished by the application of simple
syntactic rules. Generally, strings that constitute markup either begin with the
character < and end with a >, or they begin with the character & and end with a ; .
Strings of characters that are not markup are content. However, in
a CDATA section, the delimiters <![CDATA[ and ]]> are classified as markup,
while the text between them is classified as content. In addition, whitespace before
and after the outermost element is classified as markup
Tag
A markup construct that begins with < and ends with >. Tags come in three
flavors:



start-tags; for example: <section>
end-tags; for example: </section>
empty-element tags; for example: <line break/>
Element
A logical document component which either begins with a start-tag and ends with
a matching end-tag or consists only of an empty-element tag. The characters
between the start- and end-tags, if any, are the element's content, and may contain
markup, including other elements, which are called child elements. An example of
an element is <Greeting>Hello, world. </Greeting> .
Attribute
A markup construct consisting of a name/value pair that exists within a start-tag or
empty-element tag. In the example (below) the element img has two
attributes, src and alt:
<img src="madonna.jpg" alt='Foligno Madonna, by Raphael' />
Another example would be
<step number="3">Connect A to B.</step>
where the name of the attribute is "number" and the value is "3".
An XML attribute can only have a single value and each attribute can appear at
most once on each element. In the common situation where a list of multiple
values is desired, this must be done by encoding the list into a well-formed XML
attribute with some format beyond what XML defines itself. Usually this is either
a comma or semi-colon delimited list or, if the individual values are known not to
contain spaces, a space-delimited list can be used.
<div class="inner greeting-box" >Hello!</div>
where the attribute "class" has both the value "inner greeting-box" and also
indicates the two CSS class names "inner" and "greeting-box".
XML declaration
XML documents may begin by declaring some information about themselves, as
in the following example:
Conversion between XML/JSON
Page |9
Chapter # 2
Literature Review
<?xml version="1.0" encoding="UTF-8"?>
Comments
Comments may appear anywhere in a document outside other markup. Comments cannot
appear before the XML declaration. Comments start with "<!--" and end with “-->". For
compatibility with SGML, the string “--" (double-hyphen) is not allowed inside
comments; this means comments cannot be nested. The ampersand has no special
significance within comments, so entity and character references are not recognized as
such, and there is no way to represent characters outside the character set of the document
encoding.
2.2 JSON
JavaScript Object Notation, is an open standard format that uses human-readabletext to
transmit data objects consisting of attribute–value pairs. It is used primarily to transmit
data between a server and web application, as an alternative to XML.
Although originally derived from the JavaScript scripting language, JSON is a languageindependent data format. Code for parsing and generating JSON data is readily available
in a large variety of programming languages.
The JSON format was originally specified by Douglas Crockford. It is currently described
by two competing standards,RFC 7159 and ECMA-404. The ECMA standard is minimal,
describing only the allowed grammar syntax, whereas the RFC also provides some
semantic and security considerations. The official Internet media type for JSON is
application/json. The JSON filename extension is .json
2.2.1History
Douglas Crockford was the first to specify and popularize the JSON format. JSON grew
out of a perceived need for stateful, real-time server-to-browser communication without
using browser plugins such as Flash or Java applets, which were the dominant method at
the time.
The acronym JSON was coined at State Software Inc., a company co-founded by Douglas
Crockford, Chip Morningstar and Robert F. Napiltonia, starting in April 2001, and funded
by Tesla Ventures. When State was founded in early 2001 by six former employees
of Communities.com, they agreed to build a system that used standard browser
capabilities and provided an abstraction layer for Web developers to create stateful Web
applications that had a persistent duplex connection to a Web server by holding the
two HTTP connections open and recycling them before standard browser time-outs if no
further data were exchanged. The idea for the State Application Framework was
developed by Chip Morningstar at State Software. It was used in a project at
Communities.com for Cartoon Network, which used a plug-in with a proprietary
messaging format to manipulate DHTML elements (this system is also owned by 3DO).
Conversion between XML/JSON
P a g e | 10
Chapter # 2
Literature Review
Upon discovery of early Ajax capabilities, digiGroups, Noosh, and others used frames to
pass information into the user browsers' visual field without refreshing a Web
application's visual context, realizing real-time rich Web applications using only the
standard HTTP, HTML and JavaScript capabilities of Netscape 4.0.5+ and IE 5+.
Douglas Crockford then found that JavaScript could be used as an object-based
messaging format for such a system. The system was sold to Sun Microsystems,
Amazon.com and EDS. TheJSON.org Web site was launched in 2002. In December
2005, Yahoo! began offering some of its Web services in JSON. Google started offering
JSON feeds for its GData web protocol in December 2006.
Although JSON was originally based on a non-strict subset of the JavaScript scripting
language (specifically, Standard ECMA-262 3rd Edition—December 1999) and is
commonly used with that language, it is a language-independent data format. Code
for parsing and generating JSON data is readily available for a large variety
of programming languages. JSON's Web site provides a comprehensive listing of existing
JSON libraries, organized by language.
Though JSON is commonly perceived as being a subset of JavaScript and ECMAScript, it
allows some unescaped characters in strings that are illegal in JavaScript and
ECMAScript strings.
A typical mashup fetches JSON-format data from several different web servers using
an Open API.
2.2.2 DATA TYPES SYNTAX AND EXAMPLES
JSON's basic types are:






Number — a signed decimal number that may contain a fractional part and may use
exponential E notation. JSON does not allow non-numbers like NaN, nor does it
make any distinction between integer and floating-point. (Even though JavaScript
uses a double-precision floating-point format for all its numeric values, other
languages implementing JSON may encode numbers differently)
String — a sequence of zero or more Unicode characters, though characters outside
the BMP must be represented as a surrogate pair. Strings are delimited with doublequotation marks and support a backslash escaping syntax.
Boolean — either of the values true or false
Array — an ordered list of zero or more values, each of which may be of any type.
Arrays use square bracket notation with elements being comma-separated.
Object — an unordered associative array (name/value pairs). Objects are delimited
with curly brackets and use commas to separate each pair, while within each pair the
colon ':' character separates the key or name from its value. All keys must be strings
and should be distinct from each other within that object.
null— An empty value, using the word null
Conversion between XML/JSON
P a g e | 11
Chapter # 2
Literature Review
JSON generally ignores any whitespace around or between syntactic elements (values and
punctuation, but not within a string value). However JSON only recognizes four specific
whitespace characters: the space, horizontal tab, line feed, and carriage return. JSON do
es not provide or allow any sort of comment syntax.
Early versions of JSON (such as specified by RFC 4627) required that a valid JSON
"document" must consist of only an object or an array type—though they could contain
other types within them. This restriction was relaxed starting with RFC 7158, so that a
JSON document may consist entirely of any possible JSON typed value.
The following example shows a possible JSON representation describing a person.
{
"firstName": "John",
"lastName": "Smith",
"isAlive": true,
"age": 25,
"height_cm": 167.6,
"address": {
"streetAddress": "21 2nd Street",
"city": "New York",
"state": "NY",
"postalCode": "10021-3100"
},
"phoneNumbers": [
{
"type": "home",
"number": "212 555-1234"
},
{
"type": "office",
"number": "646 555-4567"
}
],
"children": [],
"spouse": null
}
2.2.3 Using JSON in JavaScript
Since JSON was derived from JavaScript and its syntax is (mostly) a subset
of the language, it is often possible to use the JavaScript eval() function to parse JSON
data. This is considered unsafe. Instead, a JSON parser library or JavaScript's native
JSON support should be used for reading and writing JSON. A correctly implemented
JSON parser will only accept valid JSON, preventing potentially malicious code from
being inadvertently executed.
var p = JSON.parse(contact);
Conversion between XML/JSON
P a g e | 12
Chapter # 2
Literature Review
Since 2010, web browsers such as Firefox and Internet Explorer have included support
for parsing JSON. As native browser support is more efficient and secure than eval(),
native JSON support is included in Edition 5 of the ECMAScript standard.
2.2.4 Applications
2.2.4.1 JSON-RPC
JSON-RPC is an RPC protocol built on JSON, as a replacement
for XML-RPC or SOAP. It is a simple protocol that defines only a handful of data types
and commands. JSON-RPC lets a system send notifications (information to the server that
does not require a response) and multiple calls to the server that can be answered out of
order. Example of a JSON-RPC 2.0 request and response using positional parameters.
--> {"jsonrpc": "2.0", "method": "subtract",
"id": 1}
<-- {"jsonrpc": "2.0", "result": 19, "id": 1}
"params": [42,
23],
2.2.4.2 Ajax
JSON is often used in Ajax techniques. Ajax is a term for the ability of
a webpage to request new data after it has loaded into the web browser, usually in
response to user actions on the displayed webpage. As part of the Ajax model, the new
data is usually incorporated into the user interface display dynamically the moment it
arrives back from the server. For example when the user is typing into a search
box, client-side code sends what they type to a server that will respond with a possible list
of items from its database. These might be displayed in a drop-down list beneath the
search box. The user may then stop typing and select the relevantstring directly. When it
was originally implemented in the mid-2000s, Ajax commonly used XML as the data
interchange format. Now many developers use JSON to pass the Ajax updates between
the server and the client.
2.2.5 Security Issues
Although JSON is intended solely as a data serialization format, its design as a
non-strict subset of the JavaScript scripting language poses several security concerns.
These concerns center on the use of a JavaScript interpreter to execute JSON text
dynamically as embedded JavaScript. This exposes a program to errant or malicious
scripts. This is a serious issue when dealing with data retrieved from the Internet.
Conversion between XML/JSON
P a g e | 13
Chapter # 2
Literature Review
2.3 Comparison between XML/JSON
JSON CODE
XML CODE
{
“first name” : “wajiha”,
“last name” : “iftikhar”,
“address” :
{
“street” : “36”,
“House num”: “1323”,
“sector” : “ G11/2”},
“phone number”:
<person>
<firstName>wajiha</firstName>
<lastName>iftikhar</lastName>
<address>
<street>36t</street>
<housenum>1323</houseum>
<sector>G11/2</sector>
</address>
<phoneNumbers>
<phoneNumber
type="home">0512213187</phoneNumber>
<phoneNumber type="fax">051
-2317036</phoneNumber>
</phoneNumbers>
[
</person>
{
“type” : “home”,
“number” : “051-2213187”
},
{
“type” : “fax”,
“number” : “051-2317036”
}
]
}
Based on these simple definitions, it's understandable that one could conclude that JSON
and XML are comparable. If wer goal is to use one or the other for simple data
Conversion between XML/JSON
P a g e | 14
Chapter # 2
Literature Review
interchange over the Internet, as exhibited by the simple examples above, that goal is
surely attainable and JSON and XML are, indeed, mostly comparable.
However, as we dig deeper into the specifications of each we begin to realize they are
completely different standards with similar goals; each with overlapping use cases where
one is much better suited than the other and where they are equivalent solutions (where
the choice is a matter of the specific use case).
2.3.1 Similarities

May be used for textual data interchange; no obscure format that is not easily
readable by humans.
 Allows data to be represented in a structured manner, providing a level of data
relationships.
 Internationalization using Unicode.
 Programming language agnostic; may be used in many programming languages.
 May be used to interface heterogeneous systems; as long as all systems use an agreed
data representation contract, communication between heterogeneous systems is
possible.
 Open standards; membership to any governing body is not required to acquire the
specifications (JSON is defined in the IETF RFC #4627 and XML is defined as
a W3C specification) and there are no restrictive licenses (JSON, XML).
2.3.2 Differences








JSON has a simple notation that may be quickly adopted by developers.
JSON's lightweight nature lends it towards improved Internet user experience by
decreasing performance bottlenecks.
JSON's simple notation, borrowed from JavaScript, makes it easier and more
performant to de/serialize the data representation to common data structures.
JSON is available in ECMAScript, 5th edition, making it available to all applications
(most notably, web browsers) with an integrated ECMAScript engine.
XML is a document markup language, providing semantics that gives additional
meaning to data; JSON does not have this ability.
XML has a broader range of specifications that cover such things as schemas for data
definition
and
validation, namespaces, stylesheets, transformations, data
expressions and many others.
XML has been around longer and is widely adopted by many businesses; affording it
greater documentation, programming language support, tooling support, community
experience, off-the-shelf product support, etc.
XML's robust standards makes it a better solution for flexible (or sometimes, rigid ...
in a beneficial way) business-to-business communication.
2.4 Result
Results illustrate the differences between JSON and XML encoding under varying
transmission scenarios.This section presents the metrics obtained for the average
measurements, compares the metrics of transmitting high versus low number of encoded
objects, and determines whether JSON and XML are statistically different for each of our
measurements.We present both scenarios' measurements.
Conversion between XML/JSON
P a g e | 15
Chapter # 2
Literature Review
2.4.1 Scenario-1
Scenario 1 is a time-consuming transmission of a large quantity of objects. Large
numbers of objects are used in order to achieve accurate average measurements. The
client sends one million encoded objects to the server for both JSON and XML. We
measure timing and resource utilizations. Tables 1 and 2 list the measurements and
respective values obtained from this trial:
JSON
XML
Number of objects
1000000
1000000
Total Time (ms)
78257.9
4546694.78
Average Time (ms)
0.08
4.55
Table 2-1 Scenario 1 JSON vs. XML Timing
Average %
Average %
Average %
User CPU
System CPU
Memory
Utilization
Utilization
Utilization
JSON
86.13
13.08
27.37
XML
54.59
45.41
29.69
Table 2-2 Scenario 1 JSON vs. XML CPU/Mem
Scenario 2
Scenario 2 is comprised of a series of smaller trialsthat determine whether JSON and
XML are statistically different according to each of our measures. The mean-comparison
t-test is used. We send 20,000, 40,000, 60,000, 80,000, and 100,000 encoded objects to
the server and collect metrics for each case. Tables 3, 4 and 5 display the metrics obtained
from these trials:
Conversion between XML/JSON
P a g e | 16
Chapter # 2
Trial 1
Objects
Literature Review
Number
JSON
XML
Of 20000
20000
Trial 1 Total Time (ms)
2213.15
61333.68
Trial 1 Average Time (ms)
0.11
3.07
Trial 2 Number Of 40000
Objects
Trial 2 Total Time (ms)
3127.99
40000
Trial 2 Average Time (ms)
3.10
0.08
123854.59
Trial 3 Number Of 60000
Objects
Trial 3 Total Time (ms)
4552.38
60000
Trial 3 Average Time (ms)
3.10
0.08
185936.27
Trial 4 Number Of 80000
Objects
Trial 4 Total Time (ms)
6006.72
80000
Trial 4 Average Time (ms)
3.10
0.08
247639.81
Trial 5 Number Of 100000
Objects
Trial 5 Total Time (ms)
7497.36
100000
Trial 5 Average Time (ms)
3.10
0.07
310017.47
TABLE 2-3 Scenario 2 JSON Vs XML Timing
Conversion between XML/JSON
P a g e | 17
Chapter # 2
Trial
Literature Review
Average %
Average %
Average %
User CPU
System
Memory
Utilization
CPU
Utilization
Utilization
1
29.07
14.80
67.97
2
83.84
15.84
68.07
3
88.01
11.99
68.06
4
88.65
11.36
68.06
5
88.70
11.30
68.06
Average %
Average %
Average %
User CPU
System
Memory
Utilization
CPU
Utilization
Table 2-4 Scenario 2 JSON CPU/Mem
Trial
Utilization
1
65.80
32.36
68.08
2
67.43
32.57
68.08
3
66.69
33.31
68.08
4
67.24
32.76
68.11
5
66.64
36
68.79
Table 2-3 Scenario 2 XML CPU/Mem
Conversion between XML/JSON
P a g e | 18
Chapter # 2
Literature Review
Figure1 illustrates JSON's average CPU and memory utilizations per trial. Figure 2
illustrates XML's average CPU and memory utilizations per trial. Figure 3 illustrates the
differences between JSON's resource utilizations and XML's resource utilizations by
plotting Figure 1 and Figure 2 on the same graph. Figures 1-3 indicate that XML appears
to use less user CPU utilization than JSON. JSON and XML encoded transmissions use
nearly the same amount of memory on the server.
JSON Resaurse Utilization
figure 1 Scenario 2 JSON Resource 1
XML Resaurce Utilization
figure 2 Scenario 2 XML Resource 1
JSON VS XML Resource Utilization
Conversion between XML/JSON
P a g e | 19
Chapter # 2
Literature Review
figure 3 Scenario 2 JSON Vs XML Resourc 1
Conversion between XML/JSON
P a g e | 20
CHAPTER # 3
Chapter # 3
System Analysis
System Analysis
In software engineering, system analysis is the partitioning of a system into
components or modules and to study how these components interact and work. Through
system analysis and synthesis, we get an idea that what should be added to achieve our
goal of developing an overall system. This chapter describes the functional and nonfunctional requirements of our project. This phase shows the important properties
associated with the situation. The main objective here is to describe a model that can be
understood and criticized by any application expert in the area whether the expert is a
programmer or not.
We build a real client project. They need to convert some XML code in to JSON or JSON
code into XML. They also want to convet JSON to JSON tree which display all nodes
array name etc.
3.1 Proposed System
We have planned to build a system that will convert XML code into JSON and
JSON code into XML. This software is also capable of convertingh JSON code into
JSON tree.We are providing a web based system that will allow users to convert
XML/JSON bidirectionally.
Conversion between XML/JSON
P a g e | 22
Chapter # 3
System Analysis
Figure: 3-1 Our system’s architecture for conversion
Above figure shows the architecture of how our system can work. Our system can get
XML code or JSON code and then convert this into other format.it can get xml code then
convert into JSON. Can convert JSON code into XML. It can also be able to convert
XML to XML tree
3.2 Functional Requirements
In the field of software engineering, a functional requirement is somewhat defined
as a function which describes the functionality of a system or a component. It basically
specifies particular results of a system. The functional requirements of proposed system
are as follows:
3.2.1 XML TO JSON
We have created two panels. User can write XML code in related panel. After pressing
the corresponding button, the code will be converted into JSON in JSON panel. As XML
Conversion between XML/JSON
P a g e | 23
Chapter # 3
System Analysis
has no array but can has similar attribute name. after conversion into json it will convert
in to JSON array
3.2.2 JSON TO XML
When user will enter Json code in related panel and after pressing the corresponding
button, the code will be converted into XML. As JSON contains array but XML does not,
so when conversion takes place, the JSON array is converted into different attributes of
XML with similar attribute name
3.2.3 XML/JSON to tree
It can convert XML/JSON code into tree form , by pressing the button tree. All attributes are
separated in heararchical manner.
3.3 Non-Functional Requirements
In software engineering, a non-functional requirement is defined as a requirement
that specifies criteria that can be used to judge the operation of a system, rather than
specific behaviours. Non-functional requirement are often called as quality of a system.
Non-functional requirement usually define the features and limitations of the system.
Following are the non-functional requirement of the Converter:
3.3.1 Usability
The system must be as user friendly as possible for all the users. Our interface is
user friendly and it is easy to operate.
3.3.2 Reliability
Reliability deals with the study and the ability of the system to perform its required
functions appropriately under stated conditions for a specific period of time. The system
is reliable enough to provide proper and accurate information to all users .Every time we
execute the application it will required result which ensure us that our application is
reliable.
3.3.3 Availability
Our system is available whenever one wants to access our system he can directly access
through it.
Conversion between XML/JSON
P a g e | 24
CHAPTER # 4
Chapter # 4
System Design
System Design
After the detailed system analysis we will move to the next step which is system
design. System design is the first step in development phase. System design is the process
of defining the components, modules, flow charts, block diagrams and interface for a
system.
One has to think before implementing that in how many parts he has to split his
project for that purpose he use to make flow charts, block diagrams and pseudo codes. A
picture is a better way to convey the idea just like a story .One of the famous phrase is “A
picture is worth a thousand words”. It means these flow charts, block diagrams and snap
shots of the project are not even helpful for the programmer but also very informative for
a non-programming person or a user.
4.1 System Overview
figure 4-1 system overview 1
Conversion Between XML/JSON
P a g e | 26
Chapter # 4
System Design
figure 4-2 system overview 2
4.2 Detailed Diagram of XML/JSON CONVERSION
In this figure 4.2, the detailed flow of the XML/JSON Convertor System is defined
in diagrammatic form. Basically the sequences of steps are designated. By the help of
this, one can properly understand the functioning of the system and it goes through which
process to achieve its goal.
Conversion Between XML/JSON
P a g e | 27
Chapter # 4
System Design
XML
REST or Java client
API’s
JSON TREE
REST or Java
client API’s
JSON
Figure 0-3 Detailed Diagram of XML/JSON CONVERSION System
Conversion Between XML/JSON
P a g e | 28
Chapter # 4
System Design
4.3 System Usecase
The purpose of a Usecase is to describe the functions a user will perform using the
target system. In figure 4-3-1, figure 4-3-2 helps user to convert data either in JSON to
XML or XML to JSON or XML to XML TREE. user will perform all these below
mentioned functions .There is no secondary actor in the system, user can have the direct
access to the system so he/she will be the primary actor of the system.
4.3.1
RUN
First user will run the eclipse server when server is synchronized then its ready to use.
figure 4-4 use case 1
figure 4-5 use case 1
Conversion Between XML/JSON
P a g e | 29
Chapter # 4
System Design
figure 4-6 use case 1
4.3.2
Web Browser
After running the server now we are able to run the project in any other web browser
(google,internet explorer,firefo,etc) ..
4.3.3 Bidirectional Conversion
XML TO JSON AND JSON TO XML
Figure 4-7 bidirectional conversion
Conversion Between XML/JSON
P a g e | 30
Chapter # 4
System Design
JSON TO XML
Figure 4-8 system use case
Conversion Between XML/JSON
P a g e | 31
Chapter # 4
System Design
CHAPTER # 5
Conversion Between XML/JSON
P a g e | 32
Chapter # 5
System Implementation
Implementation
Implementation often called as deployment or installation, refers to the final
process of moving the solution from development mode to production mode .The
implementation phase handles the issue of quality, performance, libraries and debugging.
The main goal of implementation phase is to implement a system correctly and efficiently
by using specific tools and techniques .It deals with the languages, compilers, system etc.
in order to translate design in working code. The implementation phase is set of input
(design, environmental, performance requirements), output (working system) and
techniques (transformation, conversion, testing and monitoring). This chapter discusses
the tools and techniques and the reason to select these tools for the implementation of
design.
5.1 Tools and Technologies
Selection of tools plays a vital role in developing application .Following are the tools
used for the development.
 Eclipse
 java language
 Tomcat Framework
5.1.1 Eclipse
The Eclipse Zone is brought to in partnership with Actuate. We check Actuate's free
BIRT server, BIRT iHub F-Type, that will help us to improve our BIRT content.
Eclipse is at the core of all development activities.
Eclipse has following features:
5.1.1.1 Mylyn
The advantages of Mylyn are quite well known, but it isn't until we start to use Mylyn that
we really see the benefits. we no longer need to keep a browser open on the side to see
what bugs and tasks are assigned - we get them in the task list view. And then, when a
new bug/task is assigned we get a system tray notification –
And that's just the beginning - the task focussed UI is a brilliant way of keeping track of
what files are related to user’s current task. It tooks a bit of getting used to, but once we
Conversion Between XML/JSON
P a g e | 33
Chapter # 5
System Implementation
do, it becomes second nature. Finally, we can use Mylyn to keep track of our own to-do
list by using the local repository to store our own tasks.
5.1.1.2 Software Updates
It tends to get more than it's fair share of bad press, the software update mechanism is
essential.
Being able to simply add in an update site, and get the latest version of a framework or
plug-in makes the developers life really easy. No need to worry about dependencies, or
unzipping a plug-in download to the plugins folder. Everything is managed for us through
this simple dialog.
5.1.1.3 Enterprise Java Tooling
It's a broad topic, but Eclipse has some of the best tooling available for JEE projects. It's
not a usual type of development. While we could have updated our current Eclipse
instance, we just downloaded the complete Eclipse IDE for JavaEE bundle to have a
dedicated Eclipse installation for our web based work.
The amount of functionality available here is outstanding - from wizards for Web Service
creation, excellent JSF and JPA tooling, to XML editing.
It's a simple feature but I really like the servers view that allows us to control and deploy
to usr server of choice. If usr server isn't listed as one of the available to deploy to us will
typically be able to find a plug-in to support usr server.
Conversion Between XML/JSON
P a g e | 34
Chapter # 5
5.1.1.4
System Implementation
Model Driven Development
The Eclipse Modelling Project provides a nice set of modelling tools for those using EMF
and related modelling technologies. The Ecore Tools available to work with EMF models
allow us to create and modify usr ecore through a standard tree, or using the visual Ecore
diagram editor (see below)
Figure 5-1 diagram editor
Of course, we'll need to be using EMF to benefit from these tools, but the tools
themselves
provide a compelling reason to use EMF for usr modelling. Rather than
having a UML diagram, seperate to usr source code, to represent usr model us can have
synchronisation between design and implementation using these tools.
5.1.1.5 The Smaller Features
Along with the four features we've listed above there are many other small features that
together really help to make a developer's life easy in Eclipse.
For example, this post explains how we can force a format of usr source code every time
we save - essential if we want to ensure that we're following source formatting
guidelines.
Conversion Between XML/JSON
P a g e | 35
Chapter # 5
System Implementation
Perspectives are another essential. Being able to switch the context from Plug-in
Development, JEE, Debugging or a perspective of usr own creation really helps to keep
things clear.
JUnit integration is another big win - I know it's not exclusive to Eclipse, but it's a nice
view and gives good visibility into usr testing tasks.
we'll find many plug-ins to help us along at the new Eclipse Marketplace (formerly
known as EPIC). If we need plug-ins for checking code style, static analysis or
connecting to usr version control system, we're sure to find it here.
5.1.2 Java language
Java is a general-purpose computer programming language that is concurrent,classbased, object-oriented, and specifically designed to have as few implementation
dependencies as possible. It is intended to let application developers "write once, run
anywhere" (WORA), meaning that code that runs on one platform does not need to be
recompiled to run on another. Java applications are typically compiled to bytecode that
can run on any Java virtual machine (JVM) regardless of computer architecture. Java is,
as of 2014, one of the most popular programming languages in use, particularly for clientserver web applications, with a reported 9 million developers. Java was originally
developed by James Gosling at Sun Microsystems (which has since merged into Oracle
Corporation) and released in 1995 as a core component of Sun Microsystems' Java
platform. The language derives much of its syntax from Cand C++, but it has fewer lowlevel facilities than either of them.
The original and reference implementation Java compilers, virtual machines, and class
libraries were originally released by Sun under proprietary licences. As of May 2007, in
compliance with the specifications of the Java Community Process, Sun relicensed most
of its Java technologies under the GNU General Public License. Others have also
developed alternative implementations of these Sun technologies, such as the GNU
Compiler for Java (bytecode compiler), GNU Classpath (standard libraries), and IcedTeaWeb (browser plugin for applets).
5.1.3 Tomacat Framework
Apache Tomcat (or simply Tomcat, formerly also Jakarta Tomcat) is an open
source web
server and servlet container developed
by
the Apache
Software
Foundation (ASF). Tomcat implements several Java EE specifications includingJava
Servlet, JavaServer Pages (JSP), Java EL, and WebSocket, and provides a
"pure Java" HTTP web server environment for Java code to run in.
Apache is developed and maintained by an open community of developers under the
auspices of the Apache Software Foundation, released under theApache License 2.0
license, and is open-source software.
Conversion Between XML/JSON
P a g e | 36
Chapter # 5
System Implementation
Features of Apache Tomcat
Tomcat 7.x implements the Servlet 3.0 and JSP 2.2 specifications. It requires Java
version 1.6, although previous versions have run on Java 1.1 through 1.5. Versions 5
through 6 saw improvements in garbage collection, JSP parsing, performance and
scalability. Native wrappers, known as "Tomcat Native", are available for Microsoft
Windows and Unix for platform integration
Apache Tomcat Realeses
Table 5-1 apache tomcate
Conversion Between XML/JSON
P a g e | 37
Chapter # 5
System Implementation
5.2 Proposed Algorithm
Xml toJSon and Json to XML conversion algo
On the client-side, JSON comes with a native language-compliant data structure, with
which it performs much better than corresponding DOM calls required for XML
processing. Finally, transforming JSON structures to presentational data can be easily
achieved with tools such as JSONT.
So if you're working in this space, you probably need to convert an existing XML
document to a JSON structure while preserving the following:



structure
order
information
In an ideal world, the resulting JSON structure can be converted back to its original XML
document easily. Thus it seems worthwhile to discuss some common patterns as the
foundation of a potentially bidirectional conversion process between XML and JSON. A
similar discussion can be found at BadgerFish and Yahoo-- without the reversibility
aspect though.
5.1.1 A Pragmatic Approach
A single structured XML element might come in seven flavors:
1.
2.
3.
4.
5.
6.
7.
an empty element
an element with pure text content
an empty element with attributes
an element with pure text content and attributes
an element containing elements with different names
an element containing elements with identical names
an element containing elements and contiguous text
The following table shows the corresponding conversion patterns between XML and
JSON.
Pattern XML
<e/>
1
<e>text</e>
2
3
4
5
6
JSON
Access
"e": null
o.e
"e": "text"
o.e
"e":{"@name":
"value"}
"e":
{
"@name":
<e name="value">text</e>
"value",
"#text":
"text" }
"e": { "a": "text",
<e><a>text</a><b>text</b></e>
"b": "text" }
"e": { "a": ["text",
<e><a>text</a><a>text</a></e>
"text"] }
<e name="value" />
Conversion Between XML/JSON
o.e["@name"]
o.e["@name"]
o.e["#text"]
o.e.ao.e.b
o.e.a[0]
o.e.a[1]
P a g e | 38
Chapter # 5
<e> text <a>text</a></e>
7
System Implementation
"e":
{
"#text":
o.e["#text"]
"text", "a": "text"
o.e.a
}
Please note that all patterns are considered to describe structured elements, despite the
fact that the element of pattern 7 is commonly understood as a semistructured element. A
pragmatic approach to convert an XML document to a JSON structure and vice versa can
be based on the seven patterns above. It always assumes a normalized XML document for
input and doesn't take into consideration the following:




XML declaration
processing instructions
explicit handling of namespace declarations
XML comments
5.2.2 Preserving order
JSON is built on two internal structures:


A collection of name/value pairs with unique names (associative array)
An ordered list of values (array)
An attempt to map a structured XML element...
<e>
<a>some</a>
<b>textual</b>
<a>content</a>
</e>
...to the following JSON object:
"e": {
"a": "some",
"b": "textual",
"a": "content"
}
yields an invalid result, since the name "a" is not unique in the associative array. So we
need to collect all elements of identical names in an array. Using the patterns 5 and 6
above yields the following result:
"e": {
"a": [ "some", "content" ],
"b": "textual"
}
Now we have a structure that doesn't preserve element order. This may or may not be
acceptable, depending on whether the above XML element order matters.
So, our general rules of thumb are:
Conversion Between XML/JSON
P a g e | 39
Chapter # 5
System Implementation
A structured XML element can be converted to a reversible JSON structure, if


all subelement names occur exactly once, or …
subelements with identical names are in sequence.
and
A structured XML element can be converted to an irreversible but semantically
equivalent JSON structure, if


multiple homonymous subelements occur nonsequentially, and …
element order doesn't matter.
If none of these two conditions apply, there is no pragmatic way to convert XML to
JSON using the patterns above. Here, SVG and SMIL documents, which implicitly rely
on element order, come to mind.
5.2.3 Semi-Structured XML
XML documents can contain semi-structured elements, which are elements with mixed
content of text and child elements, usually seen in documentation markup. If the textual
content is contiguous, as in:
<e>
some textual
<a>content</a>
</e>
we can apply pattern 7 and yield the following for this special case:
"e": {
"#text": "some textual",
"a": "content",
}
But how do we convert textual content mixed up with elements? For example:
<e>
some
<a>textual</a>
content
</e>
It obviously doesn't make sense in most cases to collect all text nodes in an array,
"e": {
"#text": ["some", "content"],
"a": "textual"
}
that doesn't preserve order or semantics.
Conversion Between XML/JSON
P a g e | 40
Chapter # 5
System Implementation
So the best pragmatic solution is to treat mixed semi-structured content in JSON the same
way as XML treats CDATA sections -- as unknown markup.
"e": "some <a>textual</a> content"
Another rule is that XML elements with


mixed content of text and element nodes and
CDATA sections
are converted to a reversible JSON string containing the complete XML markup
according to pattern 2 or 4.
5.2 4 Examples
Now let's look at two examples using the insight we've gained thus far. Microformats are
well suited because they are an open standard and short enough for a brief discussion.
XOXO, as a simple XHTML-based outline format, is one of several microformats. The
slightly modified sample from the Draft Specification reads:
<ol class="xoxo">
<li>Subject 1
<ol>
<li>subpoint a</li>
<li>subpoint b</li>
</ol>
</li>
<li><span>Subject 2</span>
<ol compact="compact">
<li>subpoint c</li>
<li>subpoint d</li>
</ol>
</li>
</ol>
Now we apply the patterns above to convert this XML document fragment to a JSON
structure.
1. The outer list with two list items is converted using pattern 6.
2. The first list item contains a single textual content "Subject 1" and an inner list
element. So, it can be treated according to pattern 7.
3. The first inner list is converted with pattern 6 again.
4. Pattern 5 is applied to the second item of the outer list.
5. The second inner list is converted using a combination of patterns 3 and 6.
Here is the resulting JSON structure, which is reversible without losing any information.
"ol": {
"li": [
{
"#text": "Subject 1",
Conversion Between XML/JSON
P a g e | 41
Chapter # 5
System Implementation
"ol": {
"li": ["subpoint a", "subpoint b"]
}
},
{
"span": "Subject 2",
"ol": {
"@compact": "compact",
"li": ["subpoint c", "subpoint d"]
}
}
]
}
hCalendar is another microformat based on the iCalendar standard. We'll just ignore the
fact that the iCalendar format could be more easily converted to JSON, and will look at
an hCalendar event example, which is also slightly modified so that it is a structured,
rather than mixed, semi-structured document fragment.
<span class="vevent">
<a class="url" href="http://www.web2con.com/">
<span class="summary">Web 2.0 Conference</span>
<abbr class="dtstart" title="2005-10-05">October 5</abbr>
<abbr class="dtend" title="2005-10-08">7</abbr>
<span class="location">Argent Hotel, San Francisco, CA</span>
</a>
</span>
Here, patterns 2, 3, 4, 5 and 6 are used to generate the following JSON structure:
"span": {
"a": {
"@class": "url",
"@href": "http://www.web2con.com/",
"span": [
{ "@class": "summery", "#text": "Web 2.0 Conference" },
{ "@class": "location", "#text": "Argent Hotel, San Francisco, CA" }
},
"abbr": [
{ "@class": "dtstart", "title": "2005-10-05", "#text": "October 5" },
{ "@class": "dtend", "title": "2005-10-08", "#text": "7" }
}
}
}
This example demonstrates a conversion that does not preserve the original element
order. Even if this may not change semantics here, we can do the following:
1. state that a conversion isn't sufficiently possible.
2. tolerate the result if order doesn't matter.
3. try to make our XML document more JSON-friendly.
In many cases the last point may be not acceptable, at least when the XML document is
based on existing standards. But in other cases, it may be worth the effort to consider
some subtle XML changes, which can make XML and JSON play nicely together.
Conversion Between XML/JSON
P a g e | 42
Chapter # 5
System Implementation
Changing the <abbr> elements to <span> elements in the hCalendar example would be
an improvement.
XML is a document-centric format, while JSON is a format for structured data. This
fundamental difference may be irrelevant, as XML is also capable of describing
structured data. If XML is used to describe highly structured documents, these may play
very well together with JSON.
Problems may arise, if XML documents do the following:


implicitly rely on element order
contain a lot of semi-structured data
As proof of this concept, I have implemented two Javascript functions -- xml2json and
json2xml -- based on the six patterns above, which can be used for the following:


client-side conversion
o a parsed XML document via DOM to a JSON structure
o a JSON structure to a (textual) XML document
implementing converters in other server side languages
5.2.5
XML/JSON to JSON tree
In this post we will show you how to populate the jqxTree with JSON data. The data
object below contains an array of objects, each containing “id”, “parentid”, and “text”
members.
var data = [
{
"text": "Chocolate Beverage",
"id": "1",
"parentid": "-1"
}, {
"id": "2",
"parentid": "1",
"text": "Hot Chocolate"
}, {
"id": "3",
"parentid": "1",
"text": "Peppermint Hot Chocolate"
}, {
"id": "4",
"parentid": "1",
"text": "Salted Caramel Hot Chocolate"
}, {
"id": "5",
"parentid": "1",
"text": "White Hot Chocolate"
}, {
"id": "6",
"text": "Espresso Beverage",
"parentid": "-1"
}, {
"id": "7",
"parentid": "6",
"text": "Caffe Americano"
Conversion Between XML/JSON
P a g e | 43
Chapter # 5
System Implementation
}, {
"id": "8",
"text": "Caffe Latte",
"parentid": "6"
}, {
"id": "9",
"text": "Caffe Mocha",
"parentid": "6"
}, {
"id": "10",
"text": "Cappuccino",
"parentid": "6"
}, {
"id": "11",
"text": "Pumpkin Spice Latte",
"parentid": "6"
}, {
"id": "12",
"text": "Frappuccino",
"parentid": "-1"
}, {
"id": "13",
"text": "Caffe Vanilla Frappuccino",
"parentid": "12"
}, {
"id": "15",
"text": "450 calories",
"parentid": "13"
}, {
"id": "16",
"text": "16g fat",
"parentid": "13"
}, {
"id": "17",
"text": "13g protein",
"parentid": "13"
}, {
"id": "14",
"text": "Caffe Vanilla Frappuccino Light",
"parentid": "12"
}]
We will iterate through the data and build our hierarchical data source that we will pass to
the Tree plugin. Here’s the to code for the builddata function.
varbuilddata = function () {
var source = [];
var items = [];
// build hierarchical source.
for (i = 0; i<data.length; i++) {
var item = data[i];
var label = item["text"];
varparentid = item["parentid"];
var id = item["id"];
if (items[parentid]) {
var item = { parentid: parentid, label: label, item: item };
if (!items[parentid].items) {
items[parentid].items = [];
}
items[parentid].items[items[parentid].items.length] = item;
Conversion Between XML/JSON
P a g e | 44
Chapter # 5
System Implementation
items[id] = item;
}
else {
items[id] = { parentid: parentid, label: label, item: item };
source[id] = items[id];
}
}
return source;
}
After calling the builddata function, we will have a data source which is readable by the
Tree. Let’s create the Tree plugin and populate it with data. To add the jqxTree to your
page, you should include the javascript files and cssstylesheets. You can take a look at the
list of dependencies here: JSON-tree-getting-startedThe next step is to add a DIV element
to the document’s body.
<div id='jqxTree'>
</div>
Finally, call the builddata function and create the jqxTree.
var source = builddata();
// create jqxTree
$('#jqxTree').jqxTree({ source: source, width: '350px' });
The
result
is
Conversion Between XML/JSON
a
nice
looking
JSON
TREE
P a g e | 45
CHAPTER # 6
Chapter # 6
System Testing
Testing
Testing is the process of investigating the performance or quality of a product under
service. It is stated as the process of validating and verifying of product that should fulfill
the requirements of costumers, and would meet all the requirements that guided its design
and development. The main purpose of testing is to detect failures in software’s, so as to
remove these defects and to make a system error-free.
Testing doesn’t establish that a product would work under all circumstances but it
means that it can only be established that a product would not perform under certain
circumstances. The scope of testing software lays examining and executing code in
various conditions and environment to verify that whether software does for what it is
designed for.
6.1 Software testing Strategies
Software testing strategies are mainly used to describe how the product risks are
controlled and reduced, which type of tests are performed, and which entry and exit
criteria apply. For every stage of development design, a corresponding strategy is created
to test the old and new features sets. Some of the software testing strategies are described
below:
6.1.1 White-Box testing
White-box testing mainly known as transparent box testing, glass box testing or
structural testing checks the internal working of system as compared to the functionality
shown to the end user. In white box testing, internal structure of system, as well as
programming skills are used to design test cases. The tester chooses input to check the
path through input and determine the desired outputs.
White box testing is usually applied at unit level. It can test paths with in that unit,
paths between units during integration, and between subsystems. This method can detect
many faults or error but it cannot determine unimplemented parts or missing requirements
of user
6.1.2 Black-Box testing
Black box testing tests functionality of software without having knowledge of
internal implementation. The tester only knows that the system will perform not how it
does it. The main advantage of this is that it does not require any programming
Conversion Between XML/JSON
P a g e | 47
Chapter # 6
System Testing
knowledge. It does not examine the source code, but there are conditions when tester
writes many use cases to checks something or leaving some parts of program unchecked
or untested.
Black box testing is usually applied on all levels of software testing: unit
integration, system and acceptance. It typically contains most if not testing at all higher
levels, but also dominate unit testing as well.
6.1.3 Visual testing
Visual testing is mainly used to determine what will happen at all the time of software
failure by providing the data in such a manner that developer can easily find the required
information. The main idea of visual testing is to show or present problem, rather than
describing it. It greatly increases understanding and clarity for user. Visual testing records
the whole test process, by capturing everything in video format. Output videos are
supplemented by real time tester input via picture-in-a-picture web cam and audio
commentary from microphones.
6.1.4 Testing of XML/JSON Conversion
The testing of XML/JSON conversion is undergone through all the stages of black box
and white box testing. The whole system is reviewed and tested to check whether all main
objectives of software system are achieved or not.
6.1.5 Test Case
In software engineering, a test case is a set of method through which a tester determines
whether the system is working correct or not. Test case has an input, an action, and an
expected result. The main aim of using test cases is to find defects or errors. At the end of
test, the results are compared with actual results to check if the application is working
correct or not.
Conversion Between XML/JSON
P a g e | 48
Chapter # 6
System Testing
6.1.5.1 Load Page:
Test Case ID:
TC-001
Purpose
Load the page.
Functionality to be Tested:
Test Page Loaded Successfully
Actor:
User
Pre Conditions:
XML/JSON should be written properly.
Test Data:
Load
XML/JSON={Correct=
if
XML
loaded then convert in to JSON;OR
if
JSON loaded then convert in to XML
Invalid= incorrect result}
Post Conditions:
Page Loaded successfully.
Steps:
1. In any browser write the address.
Test Results:
Basic Flow
1. In
Expected Result
any
browser
write
address.
1. Web browser
is opened and
the
user performs
the
required
action.
2. Convert into
other format.
Test Case Status:
Conversion Between XML/JSON
Fail
P a g e | 49
Chapter # 6
System Testing
Table 0-1 Load page Test Case
Load Page:
Test Case ID:
TC-002
Purpose
Load the page.
Functionality to be Tested:
Test Page Loaded Successfully
Actor:
User
Pre Conditions:
page should be loaded properly.
Test Data:
Load
XML/JSON={Correct=
if
XML
loaded then convert in to JSON;OR
if
JSON loaded then convert in to XML
Invalid= incorrect result}
Post Conditions:
Page Loaded successfully.
Steps:
1.In any browser write the address.
Test Results:
Basic Flow
3. In
Expected Result
any
browser
write
address.
4. Web browser
is opened and
the
user performs
the
required
action.
Conversion Between XML/JSON
P a g e | 50
Chapter # 6
System Testing
5. Convert into
other format.
Test Case Status:
Pass
Table 0-2 Load page Test Case
XML to JSON Conversion Test Page
Test Case ID:
TC-003
Functionality to be Tested:
Is XML is correctly converted in to JSON
Actor:
User
Pre Conditions:
Xml should b converted in to JSON properly
Test Data:
Load XML to JSON={Correct= XML
loaded convert in to JSON; Invalid=
incorrect result}
Post Conditions:
XML converted in to JSON successfully
Steps:
1.Write xml.
2. press button
3.get the results
Test Results:
Fail
XML to JSON Conversion Test Page
Test Case ID:
TC-004
Functionality to be Tested:
Is XML is correctly converted in to JSON
Actor:
User
Pre Conditions:
Xml should b converted in to JSON properly
Conversion Between XML/JSON
P a g e | 51
Chapter # 6
System Testing
Test Data:
Load XML to JSON={Correct= XML
loaded convert in to JSON; Invalid=
incorrect result}
Post Conditions:
XML converted in to JSON successfully
Steps:
1.Write xml.
2. press button
3.get the results
Test Results:
Pass
6.1.5.3 JSON to XML Conversion Test Page
Test Case ID:
TC-005
Functionality to be Tested:
Is JSON is correctly converted in to JSON
Actor:
User
Pre Conditions:
JSON should b converted in to XML properly
Test Data:
Load JSON to XML={Correct= JSON
loaded convert in to XML; Invalid=
incorrect result}
Post Conditions:
JSON converted in to XML successfully
Steps:
1.Write JSON.
2. press button
3.get the results
Test Results:
Fail
JSON to XML Conversion Test Page
Conversion Between XML/JSON
P a g e | 52
Chapter # 6
System Testing
Test Case ID:
TC-006
Functionality to be Tested:
Is JSON is correctly converted in to JSON
Actor:
User
Pre Conditions:
JSON should b converted in to XML properly
Test Data:
Load JSON to XML={Correct= JSON
loaded convert in to XML; Invalid=
incorrect result}
Post Conditions:
JSON converted in to XML successfully
Steps:
1.Write JSON.
2. press button
3.get the results
Test Results:
Pass
6.1.5.4 JSON/XML to JSON TREE Conversion Test Page
Test Case ID:
TC-007
Functionality to be Tested:
Is JSON/XML is correctly converted in to JSON
TREE
Actor:
User
Pre Conditions:
JSON/XML should b converted in to JSON TREE
properly
Test Data:
Load JSON / XML={Correct= JSON
loaded convert in to JSON TREE OR
XML loaded convert in to JSON TREE ;
Invalid= incorrect result}
Post Conditions:
JSON/XML converted
successfully
Steps:
1.Write JSON/XML.
Conversion Between XML/JSON
in
to
JSON
TREE
P a g e | 53
Chapter # 6
System Testing
2. press button
3.get the results
Test Results:
Fail
JSON/XML to JSON TREE Conversion Test Page
Test Case ID:
TC-007
Functionality to be Tested:
Is JSON/XML is correctly converted in to JSON
TREE
Actor:
User
Pre Conditions:
JSON/XML should b converted in to JSON TREE
properly
Test Data:
Load JSON / XML={Correct= JSON
loaded convert in to JSON TREE OR
XML loaded convert in to JSON TREE ;
Invalid= incorrect result}
Post Conditions:
JSON/XML converted
successfully
Steps:
1.Write JSON/XML.
in
to
JSON
TREE
2. press button
3.get the results
Test Results:
Pass
6.1.6 Results:
The results of following steps are as follows:
Run server
Conversion Between XML/JSON
P a g e | 54
Chapter # 6
Conversion Between XML/JSON
System Testing
P a g e | 55
Chapter # 6
Web
Conversion Between XML/JSON
System Testing
Browser
P a g e | 56
Chapter # 6
System Testing
XML to JSON Conversion
Conversion Between XML/JSON
P a g e | 57
Chapter # 7
Conclusion
JSON to XML Conversion
Conversion Between XML/JSON
P a g e | 58
Chapter # 7
Conclusion
XML to JSON TREE Conversion
Conversion Between XML/JSON
P a g e | 59
Chapter # 7
Conclusion
JSON TO JSON TREE
Conversion Between XML/JSON
P a g e | 60
Chapter # 7
Conclusion
Complete System Work
Conversion Between XML/JSON
P a g e | 61
Chapter # 7
Conclusion
CHAPTER # 7
Conversion Between XML/JSON
P a g e | 62
Chapter # 7
Conclusion
Conclusion and Outlook
In this chapter we conclude our project report as it has reached to its end. Here we
are presenting the summary of our project right from the first day of its beginning till the
day of successful completion. As well as, the difficulties and hurdles we faced during the
completion of this project. This chapter will also highlight our thoughts and feeling on its
successful completion.
The project “XML/JSON Conversion” was a unique experience for us as it brings
with it a great opportunity to practice all things that we have studied and learned in our
four years degree program. It improved our abilities to solve the problems occurring
during the course of project on our own and gave us confidence of building a system that
could be implemented in the real world.
7.1 Achievements and Improvements:
XML/JSON Conversion the best achievement is its so easy for user. User can easily
interact with this and feels easy while using this conversion system.user feels so relax
while converting from XML to JSON or converting from JSON to XML or converting
from JSON to JSON TREE or XML to XML TREE.
User can improve the user interface or any thing extra user can improve its tree.
User can also improve the tree edit and delete function because we are unable to build
these functions in tree.
7.2 Future Recommendations:
We have developed this system to best of our efforts and within given time
constraint. But due to advancement of sotware day by day there is always a need of
further improvement and feature additions.
In order to fully confirm the suitability of the presented method, it must still be
tested on a greater number of cases, and as this is a real client project so if client want any
other function so client will be easily able for future recommendations.
Conversion Between XML/JSON
P a g e | 63
Chapter # 7
Conclusion
7.3 Summary:
This chapter concludes the project report by looking into the improvement and
achievement made during the development. It also briefs that the improvement is not only
about the product but the developers as well. It also reviews the final result in the light of
factors discussed in chapter 3.
Conversion Between XML/JSON
P a g e | 64
Appendices
APPENDIX A
Appendix-A
Glossary
Glossary
 SGML: SGML (Standard Generalized Markup Language) is a standard for
how to specify a document markup language or tag set.
 SOAP:
SOAP is a lightweight XML based protocol for exchange of
information in a decentralized, distributed environment.
 RFC : A Request for Comments (RFC) is a formal document from the
Internet Engineering Task Force ( IETF ) that is the result of committee
drafting and subsequent review by interested parties
 ECMA Script: ECMA Script is the scripting language widely used for
client-side scripting on the web.
 XML-RPC: XML-RPC is a remote procedure call (RPC) protocol which
uses XML to encode its calls and HTTP as a transport mechanism
 JavaEE: It is a component of ANS, accompanied by an increase in heart rate
helps the body to combat potential threats by maintaining the body.
 EMF Models: EMF, the Eclipse Modelling Framework, is used to define
and implement structured data models
 GNU Classpath (standard libraries): GNU Classpath is a project aiming to
create afree softwareimplementation of the standard class library for the Java
programming language
 Java applets: Java Applets are usually used to add small, interactive
components or enhancements to a webpage. These may consist of buttons,
scrolling text, or stock tickers
 Java Servlet: Java servlet is a Java programming language program that
extends the capabilities of a server.
Conversion Between XML/JSON
P a g e | 68
APPENDIX B
Appendix-B
References
References:
[1] Basics of RESTful Services
http://dojotoolkit.org/reference-guide/1.7/quickstart/rest.html
[2] Working with Client-Side Script
http://msdn.microsoft.com/en-us/library/bb299886.aspx
[3] JSON-RPC 2.0 Specification
JSON-RPC Working Group json-rpc@googlegroups.com
[4] Client Server Communication - Java Server
http://stackoverflow.com/questions/9879895/client-server-communication-java-server
[5] Palatini P. “Apache Tomcat (or simply Tomcat) is an open source web server and
Servlet container.” DE Chanoch Wiggers 1989;97(PRF. 3):D2–EE.
[6] Tomcat: The Definitive Guide Paperback – October 30, 2007
by Jason Brittain Ian F. Darwin Aleksa Vukotic, James Goodwill.
[7] Tomcat server configuration in eclipse – May 2004
By Vivek Chopra Sing Li Ben Galbraith Jon Eaves Amit Bakore Ian F. Darwin Aleksa
Vukotic Chanoch Wiggers Nithya Vasudevan J Hypertens 1999;17(Suppl. 3):S3–S10.
[8] stackoverflow.com/questions/2620270/what-is-the-difference-between-json-and-xml
[9] “Testing client server system planning, tracking and controlling client/server
process”by Michael Abrash, Scott Adams, Leonard Adleman Alfred , Aho JJ Allaire, Andrei
Alexandrescu, Paul Allen , Eric Allman,
Marc Andreessen , Jeremy Ashkenas,
Bill Atkins
December 13, 2006
[10] Server Client automated Scripting and HTML. W3.org. Retrieved on 2012-09-11.
http://www.w3schools.com/xml/xml_applications.asp
[11] Json/Xml client server basic conversion web: https://site/mynotepad2/developernotes/javascript/javascript-convert-json-object-to-xml-string
[12]
Douglas Crockford. Douglas Crockford on Functional JavaScript (flv) (Tech
talk). blinkx. Event occurs at 2:49. [JavaScript] is also coincidentally the world's most
popular functional programming language. JavaScript is and has always been, at least
since [version] 1.2, a functional programming language.
Conversion Between XML/JSON
P a g e | 70
Appendix-B
References
[13] King, Graham (2004-12-20). "High availability Tomcat - Connect Tomcat servers to
Apache and to each other to keep your site running". JavaWorld. Retrieved 2013-02-13.
[14]
Remy Maucherat (2013-10-18). "Apache Tomcat 7 (7.0.47) - Additional
Components". Tomcat.apache.org. Retrieved 2013-11-01.
[15] Benslimane, Djamal; Schahram Dustdar; Amit Sheth (2008). "Services Mashups:
The New Generation of Web Applications". IEEE Internet Computing, vol. 12, no. 5.
Institute of Electrical and Electronics Engineers. pp. 13–15.
[16] JSON Schema implementations Crockford, Douglas (December 6, 2006). "JSON:
The Fat-Free Alternative to XML". Retrieved July 3, 2009.
[17] Hunt, Oliver (June 22, 2009). "Implement ES 3.1 JSON object". Retrieved July
3,2009.
[18]
Douglas Crockford (July 2006). "IANA Considerations". The application/json
Media Type for JavaScript Object Notation (JSON). IETF. sec. 6. RFC 4627. Retrieved
October 21, 2009.
"
Conversion Between XML/JSON
P a g e | 71