QAPI: Web Based Question

Answer Protocol Interface

Submitted as part of the requirements for:

CE902 Professional Practice and Research Methodology

Name: Ali Somer

Supervisor: Dr Norbert Voelker

Date:

Abstract
QAPI is a framework that can be used over the web to create any type of form, survey or
questionnaire. These questionnaires are then embedded to the target sites with the use of cross
domain asynchronous scripting techniques and the results are processed and stored on the
QAPI server. The framework provides a collaborative environment to bridge the gap between
the content providers and the programmers. The approach is to introduce interfaces for
different groups of users. Basically, the survey will be created by the content provider and
then the programmer will write the custom script if the mechanism was more complex than
what the tools were able to provide. The manager will be able to track the results and use
reporting features for analysing. QAPI can be used to outsource business’s questionnaire and
form needs. Although it is even possible to make login forms using QAPI, in this first
iteration of this project the focus will be on using this framework to conduct surveys because
it is a diverse form and it is the most likely usage of such a framework. The project aims to
investigate four things; The benefit of using a 3rd party tool for conducting surveys, the
advantage of the collaborative work environment, the improvement on the programmability
of questionnaires and the evaluation of the modern web technologies.
1
Table of Contents
Abstract ................................................................................................................................................... 1

Introduction ............................................................................................................................................ 4

Hypotheses ............................................................................................................................................. 4

Context and background ......................................................................................................................... 4

Goals and Objectives............................................................................................................................... 7

Developing a web application with a MVC architecture......................................................................... 7

Representing the survey with XML ......................................................................................................... 7

XML editing GUI ...................................................................................................................................... 8

Result scripts ........................................................................................................................................... 8

Client side scripting ................................................................................................................................. 9

Cross-domain scripting with AJAX and JSONP ........................................................................................ 9

Hooks and events.................................................................................................................................... 9

Charts and other adapters .................................................................................................................... 10

Usability testing .................................................................................................................................... 10

Experiments .......................................................................................................................................... 10

Live test with PricewaterhouseCoopers ............................................................................................... 10

Methodology......................................................................................................................................... 11

Technologies and Tools ......................................................................................................................... 11

Web Development Technology ............................................................................................................. 11

Java ....................................................................................................................................................... 11

Rhino ..................................................................................................................................................... 11

Apache Tomcat ..................................................................................................................................... 11

Java EE .................................................................................................................................................. 12

JSF ......................................................................................................................................................... 12

2
 PrimeFaces............................................................................................................................................ 12

Persistence layer ................................................................................................................................... 12

SQL database ........................................................................................................................................ 12

XML ....................................................................................................................................................... 12

XSLT ....................................................................................................................................................... 12

RELAX NG .............................................................................................................................................. 13

Web technologies ................................................................................................................................. 13

JavaScript .............................................................................................................................................. 13

JSON ...................................................................................................................................................... 13

JSONP .................................................................................................................................................... 13

JQuery ................................................................................................................................................... 13

JQuery-UI .............................................................................................................................................. 14

Development Model ............................................................................................................................. 14

Tests ...................................................................................................................................................... 15

Usability Testing .................................................................................................................................... 15

Iteration Tests ....................................................................................................................................... 15

Experiments .......................................................................................................................................... 15

Evaluation.............................................................................................................................................. 16

Project Plan ........................................................................................................................................... 16

References............................................................................................................................................. 17

Appendices............................................................................................................................................ 19

Figure1. Gantt chart .............................................................................................................................. 19

Figure2. LePUS3 Charts2 .................................................................................................................. 21

Figure3. LePUS3 Charts3 .................................................................................................................. 22

3
Introduction
With the rapid development of the web, companies can reach their customers at a global
scale. Conducting online surveys is a popular way of collecting information and there are
tools and websites that are available to do so, but none of these meet business’s needs and
there is a vast potential for improvement. The inadequacies that these systems face are the
level of interaction with the user, programmability, usage of AJAX/JSONP cross-domain
technologies for embedding in a web page and usability by both programmers and non-
programmers.

The company websites became so crucial that the group of people maintaining it is very
diverse. Some large corporations have a network of websites using different systems
managed by a large group of people from different backgrounds. Among these people there
can be identified three types of people responsible for a given web page, the person
responsible for the content on the page, the manager for that branch and the web developer.

The aim of this project is to provide an environment that enables these user types to work on
the same survey through different interfaces. This will remove the obstacles that held the user
back in the name of making the interface usable for everyone. Therefore the programmer can
do much more with this new custom interface. There is a separation of concerns here. The
content provider wont have to see anything about the code and the programmer is not
involved in making text amends to the questions. The manager on the other hand has a much
more simplified interface that only shows the results.

The most considerable improvement will be on what the programmer can do. The client side
QAPI libraries will enable the programmer to attach event listeners and build custom
interfaces and business logic for the embedded survey. The other thing that is now possible is
to write results scripts. These scripts take the answers given by the surveyor and output a
result. For example a simple survey could be in the form “What type of … are you?” and the
result scripts job is to calculate which type that the surveyor is.

Hypotheses
Using a collaborative customisable framework for creating embeddable surveys that has
focused interfaces for the user types will be an improvement on the current systems.

4
Context and background

In the 1960s surveys were carried out by visiting the people in their homes. There was a high
level of human interaction. By the 1970s surveys began to be made over the phone. The trust
and the response rate was decreasing. With the 1990s, the web took over. The surveys became
online forms that came in bulk emails or showed up on a web page. The human interaction
element was removed. This resulted in people having very little trust to the survey and
decreased the response rate.[1] On the other hand it was now possible to have a much large
audience. As a result there was a lot of spamming to balance the low response rate with the
high coverage.
The book “Mail and Internet Surveys: The Tailored Design Method” [1] explains how the
survey response works as a social exchange which is can be simply put as “People engage in
a social exchange with others when the perceived rewards outweigh the expected costs. ”
There is a list of suggestions and tactics to increase the deficiency of the survey by looking at
this perspective. The key elements are establishing trust, making it easy and interesting, and
providing social validation.
Development for building a survey on its own for a web page is tedious work. It is basically
building a form, handling the responses and probably saving them to a database. This may be
appropriate for just asking for a text input but it may end up being very complicated once the
questions become more complex and have logical relationships or rules. It would not be very
maintainable since the most of the things are hard-coded. It also doesn’t end with just
collecting the data. They need to be processed to give a result. This is why it is very common
to prepare survey by using 3rd party software, tools or websites.
From a business point of view it might be acceptable for a medium sized company to use
these website to make surveys but It usually is not the case with larger corporations. These
corporations have a huge amount of web presence and redirecting to a survey website which
is out of the brand theme is not a desired situation. They usually prefer to keep the users on
their site. As a result there are many different specialized implementations of surveys
throughout their websites. The surveys are different enough that they cant centralize all the
surveys in the thousands of pages that they have.
It is very easy to find a website that will enable you to create a survey. They host it as well
and give you the results in the end. Most of them support exporting to widely used tools such
as SPSS. They provide nicely designed interfaces for content providers. They can target the
audience for you by making use of bulk emails, paid surveyors or social networking. They
claim to be very secure.
But there are also a few drawbacks. Embedding to a website is done by using iframes which
has its limitations. It is as if they opened the survey page in a small window on the host page.
There is very little control over the iframe. There is very limited scripting involved. Since
5
non of these websites are targeted to programmers the closest that they get to injecting some
sort of logic into the survey is making questions skip some number of questions depending on
the answer. There is also no processing on the data. It is assumed that the processing will be
done by some other program. This might be the case for some surveys but there are lots of
surveys and quizzes that are created for the purpose of giving a result upon completion. There
is no collaboration involved. The survey creation process is designed as a one person task.
And finally, there is no interaction in the surveys. These websites only provide a way to make
questions and answers. There is nothing more to them.
There is clearly an area for improvement. The surveys can be embedded by using cross-
domain scripting. There can be JavaScript events that would enable the developer of the host
website to integrate the survey. Simple scripts that share an interface can be written to come
up with the results for a completed survey. For example a survey titled “What type of
programmer are you?” improvements on the lost human interaction can be effective, although
not necessarily efficient. For example enabling a representative for the survey to get in touch
with you with text, voice or video chat.
I have developed a prototype for embeddable surveys with PHP and MySQL before I came to
do my masters. It doesn’t have the bits about programmability or collaboration. It only makes
simple, text only surveys. It will be used as low benchmark for comparing how much better
that I can do by choosing the appropriate technologies and separating interfaces for providing
improved functionality.

6
Goals and Objectives
Developing a web application with a MVC architecture
The first goal of the project is to create a basic website. The Java EE JSF framework will be
used to do so. There will be accounts for companies and users within the companies. Basic
features such as registration, login and “forgot password” will be implemented.
The website will have several pages but the main ones will be the Welcome page where
information about the purpose of the website will be presented. There will be links for
registration and login. Once the user logs in s/he will be able to access pages about their
surveys. There will be a sortable and searchable table of existing surveys with summarized
information such as the number of surveyors and start date. Users will be able to edit their
existing surveys with the same page that they will be using to create surveys. This page will
have dynamically changing form for creating any type of question. It will also be possible to
re order, disable or manipulate questions. There will be two ways of viewing this page. One
view will be for the content provider and the other will be for the programmer. The views will
be changed from the tabs at the top of the page. Therefore both user types will be able to see
each others interface if they need to. The last of the main pages is the results page where it
would be possible to see all the answers given so far, a summary, and any other customised
result that was programmed in.
A SQL database will serve as the persistence layer. As a result of my research and prototyping
I realized the need for a SQL database that fully supports XML. I tried MySQL and Apache
Derby databases but MySQL doesn’t have any support and Derby have very limited support
for SQLXML. Therefore the database will either be Oracle or DB2.

Representing the survey with XML

This projects aims to provide a way to make a large variety of surveys. This makes it
impossible to represent the survey only with a bunch of tables and columns. The flexibility
will be obtained by representing the surveys with XML. The first task is to define a schema
for the XML. Relax NG with compact syntax will be used, so that an expressive and
lightweight schema will be formed with recursive syntax. This schema will be used to
validate the documents before they are saved. This will protect the integrity of the data.
Next step is to display these validated XML documents. Although Xquery will be used
widely for database queries XSLT will be used to create html out of these documents because
Xquery is designed for making queries and XSLT is designed for making new documents. [4]
There will be a number of XSLT files that will be combined depending on the chosen format
and templates. The format will either be form format, a summary format or editing format.
The for format will be the end product that will be embedded to the target websites. The
summary format will be used in the results page . The editing format will be used with the
editing GUI.

7
XML editing GUI
This component will be placed on the create/edit survey page. An XSLT will transform the
the survey XML into a tree of form elements such as text boxes. For creation, the XML
provided to the XSLT will be a survey XML with only one starting point question.
The user will be able to dynamically add new questions and answers as they go. There will be
a selection of templates that can be dragged and dropped. The questions and answers wont be
limited to being only plain text. There will be support for adding images, annotations and
links. Ideally it should be possible to add any html. They will also be able to assign arbitrary
meta data about the questions and answers. These values will be used by the result script
which calculates the outcome of the survey.
There will be an option for previewing the survey. This will open up in a new window where
the survey will be embedded. Almost every aspect will be the same as it would be in the
published survey except that the answers given wont be recorded and the computation for the
results that depend on the other surveyors answers will be done with a set of random answers
rather than the values from the database.
In order to save the survey the values from the dynamic form will be parsed and the new
XML document will be created on the client side with the help of JQuery. This document will
then be sent to the server where it will be validated against the schema. It will be saved to the
database if it is valid.

Result scripts
One key functionality of this project is the ability to make custom scripts that calculate the
result for a particular questionnaire. These scripts will have the current surveyor's answers as
input. It may also have the aggregate value for all the other surveyors' answers as input if the
calculation needs a comparison between the others who took the questionnaire. The results
will be in a simple string format. There will be hooks in the client side which will pass this
value that came from the server to the user functions to be used in any way they like such as
displaying the corresponding message.
There are three scripting languages that are considered. One is to simply use JavaScript and
run it on the server with Rhino. This might be a good choice because the web developer who
is embedding the survey in their website is very likely to know JavaScript. Other options are
using perl or python which are two popular, powerful and easy to learn scripting languages.
Depending on the scripting language choice, An interface needs to be defined. There should
be a way to access the surveyor's answers and the answers in the database. This input should
have a defined format. Also the output of the script should be defined. At first stage the
output can be a string but there might be need for a more complex format for some types of
surveys.
There should be a way to test and debug these scripts. By making the input in a format
similar to the request parameters in http I am planning to make it possible for programmers to
do their tests locally. But even then there is a need for error reporting when things go wrong.
8
Therefore there will be a defined response object coming in with AJAX which will have a
field for errors.

Client side scripting

There are three parts in the client side script that are working together. There is the QAPI
library which has has the main QAPI object and utility functions. The latest version of this
will be hosted at the QAPI server. The web site developers may chose to include it with this
link or making a copy of it and host it in their own server. The second part is the script that
will be provided by the web page itself. This will have event handlers for the QAPI events.
The third part is the scripts that come in as a result of the embedding the survey. These will
be mostly related to presentation such as using the JQuery UI for making the radio buttons
look nicer.

Cross-domain scripting with AJAX and JSONP

The surveys will be embedded to the website by making an AJAX call to the QAPI server.
This call can be made manually by the web page's script but the easier way will be to have
the client side QAPI library to do it automatically by looking at the DOM. The QAPI object
will find the <div/> elements with a specific class name and an attribute for the survey id. It
will then send the AJAX requests for receiving the surveys from the QAPI server. The
requests will be of type JSONP because of cross-domain restrictions.
The server side should response with the json object containing the survey. The survey id in
the request will be searched in the database and retrieved. The response will have other fields
beside the survey depending on the survey settings. For example if it is a survey has a
deadline it will return this value as well. This request will also set a cookie for the surveyor
and will have the same value in the response so that even if the cookies are disabled the
surveyor can be tracked by the JavaScript variables.
The answer will be send to the QAPI server every time a question is answered. This is
because if for some reason the user closes the web page, they can continue form where they
were left. The server should record the answers to the database if the data send is valid for
that question and answer type. It should send back an error or a success message.
The last request will be the result query. The QAPI server will calculate the result and send it
back. This response object will be passed to the user function that was bound to this hook will
then do what the developers of the website wants it to do. This response will also be included
when embedding the survey for someone who already completed the survey. It is up to the
developers of the website to enable users to take the survey more than once.

Hooks and events

This project aims to provide a framework. Therefore some parts of the working survey
system will come from other programmers who use the framework. In order to make it easy
for these two components to work together an elaborate event based observer patterned

9
system will be put in place. Please refer to the LePUS3 charts at the appendices for more
details.

Charts and other adapters

Presenting the user with charts after answering a question on a web site is a very common
practice. This can be done by the developer as well by looking at the results data, but since
this is very common I would like provide an adapter for converting a question into a chart.
This functionality will be grouped under an optional script file. The option of including
automatic charting will be in the survey GUI. Users will be able to assign metadata that
defines the chart that they want to produce such as bar charts or pie charts. Other adapters for
such as exporting the data in a different format can be implemented by using the convenient
methods for accessing the data.

Usability testing
This project aims to investigate the benefits of the collaborative development environment. In
order to measure this, the usability of the interfaces must be ensured. The three interfaces,
which are the content provider, programmer and the manager, will be tested separately.

Experiments
Several experiments will be made to evaluate the improvements this project claims. There
will be four experiments. Building a survey with and without the QAPI. Building a survey
with and without collaboration. Building a logically complex survey with QAPI and with
Survey Monkey (a popular online survey making website). Building the same survey with the
QAPI and the PHP prototype. These experiments will measure the benefit of using QAPI
framework, the improvement on the business model for creating online surveys, how much
more programmability is introduced compared to the industry standards and how the new
design decision changed the effectiveness of the program.

Live test with PricewaterhouseCoopers

The prototype that I have build with PHP is being used by some of their web pages. I will ask
them if they would like to try this new implementation. They will be able to give me
professional feedback on the usability and the market value of the system

10
Methodology
Technologies and Tools
Web Development Technology
Among the web development framework this project will make use of the latest JavaServer
Faces (JSF) extension of the Java Enterprise platform (Java EE). Other options included
ASP.NET MVC3, PHP, and Ruby on Rails. Java and C#, which is used by ASP.NET, are
similar in nature but because of its longer past and larger amount of web presence Java is
chosen. One other reason is economical. Running ASP.NET applications cost more than Java
EE applications because usually Microsoft products such as IIS and MSSQL are more
expensive. PHP is not a good fit for the rather complicated web application. The prototype
corroborates this point as it turned out to be hard to maintain. Also a possible extension to the
system might be to have a standalone desktop or a mobile version of the interfaces which is
possible with using the underlying Java classes but this would be really hard with specialized
languages like PHP or Ruby on Rails. One of the aims of this project is to be very user
friendly, especially for the content providers. JSF has 3rd party component libraries such as
Primefaces that provide easy to use human-computer interface elements. There is a JavaScript
engine for java called Rhino which will be used for questionnaire result logic.

Java
Java is a high-level platform independent object oriented programming language. It was
released by Sun Microsystems in 1995 [3] and break new ground as the first successful
language with automatic garbage collection, just in time compilation and a runtime
environment which is a virtual machine. Since then it has evolved and matured. Java will be
the backbone of the business logic. Its extensive libraries on XML will be used to read, parse
and write documents.

Rhino
Rhino is an implementation of JavaScript that is written in Java. It enables to write JavaScript
code that will be executed on the server. [5] The reason for hosing Rhino is that developers
who will be using this product probably will know decent JavaScript since they are in the
web development industry. This will enable them to write the result scripts which will
calculate the result of the surveys.

Apache Tomcat
Tomcat is a implementation of the Java Servlet and JavaServer Pages technologies [6]. It will
be used as the HTTP web server.

11
Java EE
Java Platform, Enterprise Edition is the standard Java framework for developing enterprise
web applications. [7] Version 6 will be used. The JSF2.0 will be working on top of this
framework. It has nice features such as data annotations.

JSF
The definition on the website is spot on; “A set of APIs for representing UI components and
managing their state, handling events and input validation, defining page navigation, and
supporting internationalization and accessibility. ” [8] JSF version 2.0 will be used as the
primary way of building the website.

PrimeFaces
PrimeFaces is a light weight JSF component library written by Prime Teknoloji [9]. These
components provide an easy way to create user interface elements. It makes use of the jquery-
UI libraries and the Jquery-UI themes. These will be used to increase the usability by
providing a uniform visual communication throughout the website.

Persistence layer

SQL database
A database management system that has full support for SQL/XML is essential for this
project. Apache Derby has only limited support and MySQL doesn’t have any. This leaves
Oracle DB and IBM DB2. The decision for which one to chose will be done according to the
availability. The full support of SQL/XML will make it possible to make queries against the
xml columns and directly inserting xml without converting it to a string. The database will be
used to store all the questions, answers, surveys and users.

XML
XML stands for Extensible Markup Language. It is a format that is used as a means of storing
a document or as storing and exchanging data. [10] It will be widely used when building web
pages with jsf. It also will be how the questions and surveys will be stored in the database.

12
XSLT
XSLT which stands for EXtensible Stylesheet Language transforming is a language for
transforming XML documents into other XML documents.[11] These will be mainly used for
converting the survey XML that came from the database into the html forms that will be
embedded. It is possible to combine or pipe XSL transformations. There will be a main XSLT
for converting to the forms and other XSLT will be appended depending on the survey
configuration and the theme. The matching rules can also override one an other so therefore it
is possible to do a variety of things by combining them.

RELAX NG
RELAX NG is a schema language for XML.[12] The compact syntax is very easy to write
and because of its recursive nature very appropriate for defining XML documents. It will be
used to validate and XML input to the database.

Web technologies

JavaScript
JavaScript is a prototype-based scripting language that is dynamic, weakly typed and has
first-class functions. [13] It is almost synonymous with client side code. All the client side
programming will be made with JavaScript in this project.

JSON
JSON stands for JavaScript Object Notation. It is a lightweight data-interchange format.[14]
It will be used as the transition object between the QAPI server and the host website.

JSONP
It stands for JSON with padding. It is basically a hack for making cross-domain ajax
calls.[15] Normally this is not possible due to the same origin policy which in essence says
that the requests can only be made within the same domain.[16] What it basically does is that
it inserts a <script> tag with source attribute. The requests done by the script tag can be to
other domains. The response is a JavaScript function that only returns the data.

JQuery
“jQuery is a fast and concise JavaScript Library that simplifies HTML document traversing,
event handling, animating, and Ajax interactions for rapid web development. ”[17] JQuery

13
will be used extensively on the client side QAPI object. It might even be as an extension to
the JQuery. This may result in a nice syntax for embedding surveys such as this;

$("#the_survey_container").QAPI({
theme: "dark blue",
lazy_load: true,
result_callback: function(event){...},
OnAnswer: function(event){...}
...
});

JQuery-UI
“jQuery UI provides abstractions for low-level interaction and animation, advanced effects
and high-level, themeable widgets, built on top of the jQuery JavaScript Library, that you can
use to build highly interactive web applications.”[18] Jquery-UI is used by primefaces. The
second usage of it will be on the presentation layer for the embedded surveys such as making
datepickers for date input fields or making nice looking radio buttons. Jquery-UI works with
a theme framework that enables very easy change of appearance without changing any code.

Development Model
Iterative and Agile development will be used. Agile development emphases the human aspect
of programming which is very important for this project where there are interactions with
people in many levels and different forms. Continuous input from a somebody acting as a
client will always be considered when planing the next steps. This agile development will fit
into the iterations that I have described as my goals.
Even though I will be working on the project alone I will make use of a local git repository
for tracking my changes and tagging the iterations.

14
Tests
Usability Testing
“Key task tesing” will be carried out as defined in Steve Krug's Book[2]. It is basically asking
someone to do certain tasks and observing how well they do it. It would be ideal if the
interactions can be recorded by a camera for further analysis. When doing the usability tests
for each user type I will try to get someone that fits the role. For example I will have a
developer test the interface that is for the developers.

Iteration Tests
There will be test at end of every iteration to ensure that the next iteration will be build on a
reasonably bug free base. Most of my iteration are connected in a way that they need the
proceeding iterations to work properly. These tests will include unit testing, integration
testing depending on the tested iteration.

Experiments
There will be series of controlled experiments that aim to measure the difference made by
using QAPI for making surveys. I wont be participating in these experiments because I
would be biased. I will only will be observing.

Hopefully I will have two programmers with similar skill sets to do the first experiment
where one programmer uses QAPI and the other doesn’t.

For the second experiment where I measure the benefits of working collaboratively, I will
have one programmer and one non-programmer person as the content provider. First I will let
them try to make a survey about something that the content provider will chose. I will add in
some programmatic twists to the survey and have give them a certain amount of time to
finish. The base line for the test will be these surveys. I assume that the programmer would
not get all the details right in the content because s/he will only receive a brief explanation of
the survey. The content provider on the other hand would probably wont be able to put in all
the programming into the survey. Then as the second part of this experiment they will work
on a new topic again chosen by the content provider with similar programmatic twists added
by me. After the same amount of time has passes we will compare the results.

The third experiment is a comparison between QAPI and a popular survey generating
website. I will create a scenario for a survey which includes both of the programmability
aspects. So it will have a logic for giving back a result and a logic for interacting with the rest
of the page. Then once again I will have two programmers implement the same survey by
using different tools.

The fourth experiment will compare QAPI with my PHP prototype the same way as above.
This might give a comparison between two tools that were designed to make embedded
surveys.
15
Evaluation
The evaluation will depend on the experiment results, the usability tests, the iteration tests
and the benefit of novel features. The experiments are well defined at this stage but because
of the agile nature of the development of this project the details of iteration tests are
unknown. Nevertheless the iteration tests will test the general functionality that was
implemented by that particular iteration and therefore provide an insight on how well that
iteration was. The most important test will be when it will be used in real life for the first
time.

Project Plan
Please see the appendix for the Gantt chart. Every group of tasks is an iteration. The ends if
the iterations (usually ending with the iteration test) are milestones.

16
References
[1] Dillman A. Don et al, Mail and Internet Surveys: The Tailored Design Method. New
Jersey: John Wiley & Sons, 2009

[2] Steve Krug, Don't Make Me Think!: A Common Sense Approach to Web Usability.
Berkeley CA: New Riders, 2006

[3] What is Java and why do I need it? (n.d.) [Online]. Available:
http://www.java.com/en/download/faq/whatis_java.xml

[4] Working XML: Comparing XSLT 2.0 and Xquery (04 Apr 2006) [Online]. Available:
http://www.ibm.com/developerworks/xml/library/x-wxxm34/index.html

[5] Rhino - JavaScript for Java (01 Feb 2012) [Online]. Available:
http://www.mozilla.org/rhino/

[6] Apache Tomcat (n.d.) [Online]. Available: http://en.wikipedia.org/wiki/Apache_Tomcat

[7] Java EE at a Glance (n.d.) [Online]. Available:

http://www.oracle.com/technetwork/java/javaee/overview/index.html

[8] JavaServer Faces Technology Overview (n.d.) [Online]. Available:

http://www.oracle.com/technetwork/java/javaee/overview-140548.html

[9] Why PrimeFaces (n.d.) [Online]. Available: http://primefaces.org/whyprimefaces.html

[10] Extensible Markup Language (XML) (24 Jan 2012) [Online]. Available:
http://www.w3.org/XML/

[11] XSL Transformations (XSLT) (n.d.)[Online]. Available: http://www.w3.org/TR/xslt

[12] RELAX NG home page (n.d.)[Online]. Available: http://relaxng.org/

17
[13] JavaScript (n.d.)[Online]. Available: http://en.wikipedia.org/wiki/JavaScript

[14] Introducing JSON (n.d.)[Online]. Available: http://www.json.org/

[15] Defining Safer JSON-P (n.d.)[Online]. Available: http://json-p.org/

[16] Same Origin Policy (n.d.)[Online]. Available:

http://www.w3.org/Security/wiki/Same_Origin_Policy

[17] JQuery (n.d.)[Online]. Available: http://jquery.com/

[18] JQuery UI(n.d.)[Online]. Available: http://jqueryui.com/

18
Appendices
Figure1. Gantt chart

19
. 20
Figure 2. LePUS3 Charts1

21
Figure 3. LePUS3 Charts2

22