thesis-walsh-jason-april-15-2013x

hundredcarriageΛογισμικό & κατασκευή λογ/κού

3 Νοε 2013 (πριν από 3 χρόνια και 10 μήνες)

186 εμφανίσεις


Title
Page





Table of Contents

INTRODUCTION

................................
................................
................................
................................
........

5

P
ROJECT
O
VERVIEW

................................
................................
................................
................................
................

7

R
ELATED
W
ORK

................................
................................
................................
................................
.......................

8

SoapUI
................................
................................
................................
................................
................................
..........

8

SoapSonar

................................
................................
................................
................................
................................
..

9

Limitations

................................
................................
................................
................................
................................

9

T
EST
S
UITE
F
EATURES

................................
................................
................................
................................
.........

10

DEVELOPMENT TOOLS

................................
................................
................................
.......................

11

J
AVA

................................
................................
................................
................................
................................
.........

11

Version

................................
................................
................................
................................
................................
.......

12

JPA

................................
................................
................................
................................
................................
...............

12

Swing

................................
................................
................................
................................
................................
..........

13

JUnit

................................
................................
................................
................................
................................
............

14

ANT

................................
................................
................................
................................
................................
.............

14

P
YTHON

................................
................................
................................
................................
................................
..

14

Version

................................
................................
................................
................................
................................
.......

14

SQL

................................
................................
................................
................................
................................
..........

15

XPath

................................
................................
................................
................................
................................
..........

15

E
CLIPSE

................................
................................
................................
................................
................................
...

16

Version

................................
................................
................................
................................
................................
.......

16

AgileJ
................................
................................
................................
................................
................................
...........

16

Eclipse Diver

................................
................................
................................
................................
...........................

17

JPA Diagram Editor

................................
................................
................................
................................
.............

17

Code Coverage

................................
................................
................................
................................
........................

17

Statistics

................................
................................
................................
................................
................................
...

17

Subclipse

................................
................................
................................
................................
................................
...

17

P
OSTGRE
SQL

................................
................................
................................
................................
.........................

17

Version

................................
................................
................................
................................
................................
.......

18

PL/Python

................................
................................
................................
................................
................................

18

DbVisualizer

................................
................................
................................
................................
............................

18

T
EXT
W
RANGLER

................................
................................
................................
................................
..................

19

Version

................................
................................
................................
................................
................................
.......

19

D
ROPBOX

................................
................................
................................
................................
................................

19

S
UBVERSION

................................
................................
................................
................................
...........................

19

Version

................................
................................
................................
................................
................................
.......

20

XML COMPARISON

................................
................................
................................
................................

20

XP
ATH

................................
................................
................................
................................
................................
.....

21

Select an XML Column

................................
................................
................................
................................
........

22

Select C
omplex XML Node(s) based on Name and Location

................................
............................

22

Select Simple XML Node(s) based on Name and Location

................................
................................

22

Select XML Node(s) based on Name and Wildcard Location

................................
...........................

22

Select Value(s) of Simple XML Node(s)

................................
................................
................................
......

22

Select an XML Column containing Attributes

................................
................................
.........................

22

Select an XML Node having a Specific Attribute

................................
................................
....................

23

Select Value(s) of a Specific Attribute

................................
................................
................................
.........

23

Difficulties

................................
................................
................................
................................
................................

23


XML

S
CHEMA

D
EFINITION
(XSD)

................................
................................
................................
.....................

23

Difficulties

................................
................................
................................
................................
................................

25

XML

S
ORT
C
OMPARE

................................
................................
................................
................................
...........

26

Sorting

................................
................................
................................
................................
................................
.......

29

Base Algorithm

................................
................................
................................
................................
......................

30

Sort Algorithm

................................
................................
................................
................................
.......................

32

Detail Algorithm

................................
................................
................................
................................
...................

33

Sorted Examp
les
................................
................................
................................
................................
....................

39

S
UMMARY

................................
................................
................................
................................
...............................

57

TEST SUITE DESIGN

................................
................................
................................
.............................

58

U
SE
C
ASES

................................
................................
................................
................................
..............................

58

Start Up

................................
................................
................................
................................
................................
.....

58

Quit

................................
................................
................................
................................
................................
..............

59

Add Service

................................
................................
................................
................................
..............................

59

View Service

................................
................................
................................
................................
............................

62

Remove Service

................................
................................
................................
................................
......................

62

Add Endpoint

................................
................................
................................
................................
..........................

63

View Endpoint

................................
................................
................................
................................
........................

68

Remove Endpoint

................................
................................
................................
................................
..................

68

Add Schema

................................
................................
................................
................................
.............................

71

View Schema

................................
................................
................................
................................
...........................

72

One Time Request

................................
................................
................................
................................
.................

72

Load Prepared Input

................................
................................
................................
................................
...........

74

Functional Test

................................
................................
................................
................................
......................

75

View Functional Test

................................
................................
................................
................................
..........

78

Export F
unctional Test

................................
................................
................................
................................
......

79

Remove Functional Test

................................
................................
................................
................................
....

81

Comparison Test

................................
................................
................................
................................
...................

81

View Comparison Test

................................
................................
................................
................................
........

84

Export Comparison Test Results

................................
................................
................................
....................

85

Remove Comparison Test

................................
................................
................................
................................
.

86

A
RCHITECTURE

................................
................................
................................
................................
......................

87

Class Diagrams

................................
................................
................................
................................
......................

87

Sequence Diagrams

................................
................................
................................
................................
.............

87

D
ESIGN
P
AT
TERNS

................................
................................
................................
................................
................

88

Bridge

................................
................................
................................
................................
................................
.........

88

Factory

................................
................................
................................
................................
................................
......

89

Observer

................................
................................
................................
................................
................................
....

90

Mediator

................................
................................
................................
................................
................................
...

91

Singleton

................................
................................
................................
................................
................................
...

91

Composite

................................
................................
................................
................................
................................
.

93

Template

................................
................................
................................
................................
................................
...

94

Adapter

................................
................................
................................
................................
................................
......

94

D
ATABASE

................................
................................
................................
................................
..............................

96

Relations

................................
................................
................................
................................
................................
...

96

Model

................................
................................
................................
................................
................................
..........

97

JPA Diagrams
................................
................................
................................
................................
..........................

97

C
ONSIDERATIONS

................................
................................
................................
................................
..................

97

Xml Clients

................................
................................
................................
................................
...............................

97


Text Data Type
................................
................................
................................
................................
.......................

98

Boolean Data Type
................................
................................
................................
................................
...............

99

Python Sorted Element

................................
................................
................................
................................
...

100

Surrogate Keys

................................
................................
................................
................................
....................

100

Serial Data Type
................................
................................
................................
................................
.................

100

Named Queries
................................
................................
................................
................................
....................

101

Entity Manager Access

................................
................................
................................
................................
....

101

JPA vs JDBC

................................
................................
................................
................................
...........................

102

JPA Cascade

................................
................................
................................
................................
..........................

102

D
IFFICULTIES

................................
................................
................................
................................
......................

103

XML Data Type

................................
................................
................................
................................
...................

103

Java Stored Procedures

................................
................................
................................
................................
...

103

JPA En
hancement

................................
................................
................................
................................
..............

104

JPA Embedded Primary Keys

................................
................................
................................
........................

106

JPA Entity Access

................................
................................
................................
................................
................

107

CONCLUSION

................................
................................
................................
................................
.........

108

F
UTURE
W
ORK

................................
................................
................................
................................
...................

109

Enhanced Detail
Comparison

................................
................................
................................
......................

109

Performance Tools

................................
................................
................................
................................
............

109

Full Function JDBC Loader

................................
................................
................................
............................

110

SOAP Client

................................
................................
................................
................................
...........................

110

JMS Client

................................
................................
................................
................................
..............................

110

RESOURCES

................................
................................
................................
................................
...........

110


Introduction


The Internet started a revolution. It began small but over the course of a decade
Hyper Text
Markup Language (
HTML
)

was used to make more information available for human
consumption than ever before. Billions of web pages appeared. Unfortunately, these web
pages contained more information than any human could ever hope to consume. The
information was there
,

but how cou
ld we best make use of it
?

A new vision of machines
processing, interpreting, and sharing data across the Internet began to form.


In order for this collaboration to take place between computers, it was necessary to
develop an Electronic Data Exchange
(EDI).

HTML worked incredibly well as a m
edium to
put the wealth of data

avai
lable on the Internet

into a form that humans could easily
understand. The HTML is, however, completely insufficient to function as a useful EDI that
would allow comp
uters from
all over the world
to collaborate across the Internet. A new
language designed for machine, instead of human, consumption was needed. It arrived in
the form of the Extensible Markup Language (XML)
.
(Chowdhury, & Choudhary, 2003, p.
5
)
.

Today XML is an
industry
-
standard, extensible, system
-
independent way of
representing and exchanging data. This is achieved in two ways:

-

The use

of a tagging mechanism in which the tags indicate the content and
str
ucture of the data they enclose.
The fact that tags are us
er
-
defined is what
gives XML its extensib
ility.

-

The portability of data is ensured by the use of DTD’s [and XSD’s], or XML
Schemas. [Schemas] describe the tags, and the order in which they can appear in
an XML document. These provide a consistent understan
ding of the XML data by
different applications
.

(Chowdhury, & Choudhary, 2003, p.
5
-
6
)
.



The language itself was not enough. In order for XML to reach its true potential, well
-
accepted standards were needed. Once these standards were defined, a whole new
world of
information sharing became available. The very nature of XML allows it

to be

used across
different types of machines with different hardware and operating systems. Programs
written in completely different languages and running in completely differ
ent
environments now had a way to communicate with each other.


The specialized pieces of software that allow applications to use the Internet to conduct
business are known as Web Services. Web Services make use of XML to provide interfaces
for these vas
tly different systems to communicate with each other. Many different
transport protocols, including HTTP and FTP, are used to send the data between these
systems but XML has allowed the interface to be universal.


Attempts had been made before to initiate

this type of communication between machines.
Early EDI’s and value added networks, even those using the same protocols currently used
by XML with great success, were not nearly as successful. The primary reason for this
failure lies in the uniqueness of d
ata between enterprises. It is unlikely that two different
systems would be used for similar information and even more unlikely, even if it the data
elements were similar, that it would be structured in a similar fashion. Additionally, the
systems were un
likely to be running on compatible hardware. As a result, many early
attempts at this type of communication were proprietary solutions, which were difficult to
implement, maintain, and interface with outside systems. XML and Web Services have

provided a
universal method for structuring and transporting data between systems
.
(Chowdhury, & Choudhary, 2003, p.
15
-
17
)
.

Project Overview


Web services are now used by just about every enterprise as a means for transferring data.
However, as their popularity has

grown another need has also grown. Not unlike other
pieces of software, web services need to be tested. While manual testing still has its place,
most systems benefit greatly from automated testing. Since these types of tests are much
easier to run, autom
ated tests can be run more often, which leads to increased efficiency
and software quality.


The Test Suite application, developed as part of this project,

will allow the automated
testing of web service applications. This includes the validation of XSD/D
TD, the automatic
submission of valid requests to multiple service endpoints, validation and storage of
responses, and comparison of XML responses.

The automated comparison of XML
documents is the true backbone of this project.



Automating the request /
response aspect of web service testing is only part of the
problem. After the responses have been recorded, there is still manual intervention
required to validate the content of the response. One approach to the automation of
response validation is the de
velopment of detailed unit test scenarios. While this approach
does automate the validation, it requires a great deal of knowledge about the application

being tested in order to develop the unit test scenarios. This is inherently a proprietary
solution to
the problem.


There is currently no universally accepted algorithm for the comparison of XML
documents. As part of this project,
the author

made

a formal investigation into the
comparison of XML data.

The end result is the XML Sort Compare algorithm. This

algorithm
provides a general automated solution for comparing and validating XML documents. It is
the author’s
hope that this algorithm can move XML testing beyond proprietary testing, just
as XML, itself, moved computer
-
to
-
computer communication beyond p
roprietary solutions.

Related Work


There are several existing
tools

that offer similar functionality. Two of the most popular
tools

are SoapSonar and SoapUI. Both of these
tools

provide the means for functional
testing but it is a different nature than what I
have provided with the Test Suite application
and the XML Sort Compare algorithm
.

SoapUI

SoapUI is an open source functional testing tool.
It allows for the quick creation an
d
exec
u
tion of “
automated functional, regression, compliance, and load tests.”
The tool works
on most standard platforms and provides
support for most standard protocols. The
company boasts that it is “the world’s most complete testing tool!”
("What is soa
pUI? |
About SoapUI", n.d.)
.



SoapSonar

SoapSonar is a “
Global Leader in Service and API Testing.


The application supports “
HTML,
XML, SOAP, REST, and JSON

using
the


HTTP/s
FTP/s, SFTP, IBM MQ, Tibco

EMS, [and]
Weblogic JMS
” transport protocols
.
The product is intended to be used for “
Functional,
Automation, Performance, C
ompliance, and Security Testing” and provides
“[comprehensive]

out
-
of
-
the box standards support for OASIS and W3C standards.


("SOA
PSonar
-

SOA Service Testing and Diagnostics", n.d.)
.

Limitations


SoapUI is intended as part of unit test suite. Users write test cases and validate the results
of specific service against these test cases. SoapSonar is a little broader but is still built

on
the concept of pre
-
established test cases.



Test Suite

allow
s

for the more general comparison of XML responses. This will be useful in
running regression tests when making application changes, migrating environments, etc.
The benefit of the more gene
ric approach of comparing the actual XML responses of
multiple endpoints is that the comparison results can highlight differences and potential
problems that might not have been found by an existing test case or require a new test
case.



Additionally, th
is
tool

provide
s

features that allow users to store the results of any past test
runs that can be used in future comparisons or exported for documentation. This will
provide a useful timeline of how application changes have affected the application.




Almost all of the existing
tools

offer limited functionality unless you are willing to pay
expensive licensing fees. An example of such a feature would be data
-
driven request
creation.

SoapSonar has an additional limitation in that it will only run on a
W
indows
machine.
The Test Suite
tool
is platform independent.

Test Suite Features




Validate schema/xsd files provided by the user



Store schema/xsd files for future use



Connect to web services via HTTPS/HTTP

o

Optional Enhancement: Support SOAP

o

Optional Enhanc
ement: Support REST

o

Optional Enhancement: Support JMS



Store service connection properties and endpoints for future use



Accept pre
-
built request strings to be used in a test

o

Optional Enhancement: Data
-
Driven Testing



Dynamically build XML request strings
using data from:



Optional Enhancement: Support Excel File



Optional Enhancement: Support Delimited Text File



Optional Enhancement: Support Fixed Width Text File



Optional Enhancement: Support JDBC



Optional Enhancement: Support User Input



Validate the struct
ure of xml responses



Compare responses from a previous test run to the results of a current run




Send requests to multiple endpoints during a test run and compare the results



Store the configuration used for a particular test run



Store the results of test
s for future use



Allow configurable multi
-
threading for large tests



Record stats for each test run, including:

o

Test Start/End Time

o

Response Time of Web Service

o

Process Time (response time + internal operation time)

o

Number of Requests

o

Thread Count

o

Servic
e Configurations Used

o

Description of Test



Allow users to export test results (settings, input, output, comparisons, stats)



Provide User Interface for the application

o

Optional Enhancement: Provide GUI



Provide Performance Statistics

o

Provide Response Time for each web service call

o

Provide Average Response Time for a service endpoint



Allow users to submit one
-
time requests to a previously defined endpoint


Development Tools

Java



The Java programming language “
is the underlying techno
logy that powers state
-
of
-
the
-
art
programs including utilities, games, and business applications.
[It]

runs on more than 850
million personal computers worldwide, and on billions of devices worldwide, including
mobile and TV devices.

("What is Java and wh
y do I need it?", n.d.)
.
Java was used as the
primary
programming

language for this project.

Version

The
version of Java used in this

project is Java SE 1.6.

JPA

Database persistence in this project was handled exclusively through the use of the Java
Per
sistence API. This API
is a much simpler approach to Object
-
relational mapping (ORM)
than previous Java persistence layers.



Persistence is simply a higher
-
level abstraction above Java Database Connectivity (JDBC).
By exposing the database as objects to
the developer, backing rows may be queried, loaded,
updated, or removed without explicitly having to go through a contracted API or language
such as SQL.


(Rubinger, Monson
-
Haefel, & Burke, 2010, p.
17
)
.
In previous iterations,
persistence was included in
the EJB specification. As of EJB 3.0, JPA handles persistence
using POJO Java classes and annotations.
(Rubinger, Monson
-
Haefel, & Burke, 2010, p.
17
)
.

Entity Beans use object
-
relational mapping to create Java representations of database
obje
cts.
(Rubinger, Monson
-
Haefel, & Burke, 2010, p.
16
)
.





Persistence
provides an ease
-
of
-
use abstraction on top of JDBC so that your code may be
isolated from the database and vendor
-
specific peculiarities and optimizations.
” JPA also
provides support to automatically generate
JPA
entities from existing database objects and

generate database objects from existing JPA entities
. This is commonly referred to as an
object
-
relational mapping engine.



In addition to object mappings, this service also
provides a query
-
language that is very SQL
-
like but is tailored to work with Java objects
rather than a relational schema.



In JPA, the
EntityMan
ager

is the main component
used in database transactions.

This
class manages the relationship between JPA entities and the underlying data

store.

It
provides APIs for creating queries, finding objects, synchronizing, and inserting objects into
the database.


Prior to interaction with the
EntityManager
, JPA entities are merely Java
objects and have no relationship with the actual persistence source. The JPA EntityManager
can be used with Java EE EJBs and in Java SE applications.
(Rubinger, Monson
-
Haefe
l, &
Burke, 2010, p.
127
-
128
)
.


Provider


The JPA provider used for this project is OpenJPA version 2.2
.1.

Swing

Java Swing components were used to create a simple Graphical User Interface (GUI) for the
Test Suite
tool
.

Swing GUI components [include]
everything from buttons to split panes to
tables. Many components are capable of sorting, printing, and drag and drop, to name a few
of the supported features.

The look and feel of Swing applications is pluggable, allowing a

choice of look and feel.


("About the JFC and Swing (The Java™ Tutorials > Creating a GUI
With JFC/Swing > Getting Started with Swing)", n.d.)
.


JUnit

JUnit is a unit test framework for Java applications. The JUnit fr
amework was used to create
a unit test suite for this project.


Version


The version of
JUnit
used in this project is JUnit
4
.


ANT

Python

The Python programming language was used to create a version of the XML Sort Compare
algorithm that can run inside PostgreSQL
as a
database

function
.


Python is a remarkably
powerful dynamic programming language that is used in a wide variety of

applicat
ion
domains.


("Python Programming Language


Official Website", n.d.)
.
It is often compared
to other populated programming languages, such as Java and Perl. One of its main
advantages is that it allows you to quickly
develop

the

code that you need.

("Python
Programmi
ng Language


Official Website", n.d.)
.


Version

The version of Python used in this project is 3.2. This is the version compatible with the
version of PostgreSQL being used.


SQL

SQL was used to both create the underlying database for the Test Suite appli
cation and to
perform operations against the database.


The SQL language may be considered one of the
major reasons for the commercial success of relational databases.

(Elmasri, & Navathe,
2011, p.
87
-
88
)
.
The advent of standard query language for
relational databases

allowed
users to worry less about migrating between different database management systems.

(Elmasri, & Navathe, 2011, p.
87
-
88
)
.



The SQL Language provides a higher
-
level declarative language interface, so the user only
specifies what the result is to be,

leaving the actual optimization and decisions on how to
execute the query to the DBMS.


(Elmasri, & Navathe, 2011, p.
87
-
88
)
.
SQL is based on both
relational algebra and tuple relational calculus.

(Elmasri, & Navathe, 2011, p.
87
-
88
)
.

However, the SQL syntax is more user
-
friendly than either of the two formal languages.


(Elmasri, & Navathe, 2011, p.
87
-
88
)
.
SQL is considered bot
h a Data Definition Language
(DDL) and a Data Manipulation Language (DML) as it has statements to define data and
execute queries and updates on the data.
(Elmasri, & Navathe, 2011, p.
87
-
88
)
.

It also has
rules for embedding SQL statements into a general
-
purpose programming language such as
Java, COBOL, or C/C++
.


(Elmasri, & Navathe, 2011, p.
87
-
88
)
.


XPath

XPath is not
present in any of the deliverables created for this project. Howe
ver, it did serve
a vital role the research and design phases of the project. XPath was ultimately deemed to
be insufficient for creating a general purpose XML comparison algorithm but it is
still a

valuable tool.

XPath provides a common syntax for navigating an XML document.
This is
accomplished through the
addressing of XML
nodes and
use of a path notation
to reference
the addressed nodes. XPath can be used to determine the existence and
values of XML
nodes

as well as to determine if nodes match a specific pattern.

("XML Path Language
(XPath)", n.d.)
.


Eclipse

The primary development environment for this project was the Eclipse Interactive
Development Environment (IDE). “
Considered by many to be the best Java development
tool available, the Eclipse

IDE for Java

Developers provides superior Java editing w
ith
validation, incremental compilation, cross
-
referencing, code assist; an XML Editor;

Mylyn;
a
nd much more
.”

("Eclipse
-

The Eclipse Foundation open source community website",
n.d.)
.


Version

The version of Eclipse used in this project is 4.2 (Juno).

AgileJ

AgileJ is an eclipse plugin that can be used to generate class diagrams. This allows
developers to gain a better understanding of how classes and methods interact with each
other. It is also a powerful tool for creating self
-
documenting code.


Eclip
se Diver

Diver is an eclipse plugin that can be used to generate static sequence diagrams. This
allows developers to gain a better understanding of how classes and methods interact with
each other. It is also a powerful tool for creating self
-
documenting c
ode.

JPA
Diagram Editor


JPA Diagram editor is an eclipse plugin that can be used to generate diagrams representing
the JPA entities in a project. This allows developers to gain a better understanding of how
entities interact with each other.

Code Covera
ge

Statistics

Subclipse

Subclipse is an eclipse plugin that can be used to interact with a Subversion repository.
This allows developers to keep changes in synch with other team members and keep a
record of all software changes.

PostgreSQL

The database us
ed for this project was PostgreSQL.
It was used as the backend for the Test
Suite application and to test the XML Sort Compare algorithm in a standalone fashion.


PostgreSQL is a powerful, open source object
-
relational database system.

("PostgreSQL:
Abou
t", n.d.).
It provides
many of the same features as competing
commercial products.
It
supports most standard data types and also includes some data types not available in other
systems, such as TEXT and BOOLEAN.

Interfaces are available for many popular

pr
ogramming languages such as Java and C/C++.
("PostgreSQL: About", n.d.).

“As such,
PostgreSQL is not only a powerful database system capable of running the enterprise, it is a
development platform upon which to develop in
-
house, web, or commercial software
products that require a capable RDBMS.” ("PostgreSQL: About", n.d.).


Version

The version of PostgreSQL used in this project is 9.2.

JDBC Driver


The version of the
PostgreSQL
JDBC driver used
in

this project is
postgresql
-
9.1
-
901.jdbc3.jar
.

PL/Python

The procedural language used to create the database version of the XML Sort Compare
algorithm was PL/
Python, which

allows database functions to be written using
the

Python
programming language
.


Postgre
SQL imposes no restrictions on what users can do within a
Python function. Therefore, the language is available as an untrusted language and
developers m
ust ensure that
the

Python
functions are not performing any unintended
actions.
("PostgreSQL: Documentation: 9.1: PL/Python
-

Python Pro
cedural Language",
n.d.)
.


Db
Visualize
r

The database object models for this project were created using
the
DbVisualizer

tool
, which
provides support to create and modify database objects. It also allows users to create a

visual representation of the database.
("Database Management Software Tools
-

DbVisualizer", n.d.).



Text Wrangler

Some development was performed outside of the Eclipse IDE. Text Wrangler, “[a]
programmer’s text editor, featuring syntax coloring and function navigation for
HTML/XHTML, XML, PHP, JavaScript, Perl, Python, Ruby, Lua, Java, ANSI C, C++, Objective
-
C, and m
ore
[,]” was used for the development SQL, Python, and some XML
.

("Bare Bones
Software | TextWrangler Tour", n.d.)
.

Version


The version of Text Wrangler used in this project is 4.0.1.


Dropbox

Dropbox was used as a backup storage location for thesis docu
ments during the project.

Dropbox is a free service that lets you bring all your photos, docs, and videos anywhere.
This means that any file you save to your Dropbox will automatically save to all your
computers, phones and even the Dropbox website
.


("D
ropbox", n.d.)
.


Subversion

Subversion was used as the primary version control system for this project.

Subversion
exists to be universally recognized and adopted as an open
-
source, centralized version
control system characterized by its reliability as
a safe haven for valuable data; the

simplicity of its model and usage; and its ability to support the needs of a wide variety of
users and projects, from individuals to large
-
scale enterprise operations.


("Apache
Subversion", n.d.).


Version

The version of Subversion used in this project is 1.6.2.

XML Comparison


The xml data type is unusual in that it does not provide any comparison operators. This is
because there is no well
-
defined and univ
ersally useful comparison algorithm for XML
data.

("PostgreSQL: Documentation: 9.2: XML Type", n.d.)
.



That
sentiment

was
one
of the driving forces in
the
development of

an XML comparison
algorithm.
The ultimate goal of this effort was to create a generic algorithm that could be
used to compare any XML documents. Ideally, the algorithm would have no unrealistic
restrictions on the XML documents and would require no additi
onal user insight on how to
compare the documents. Finally, since the sentiment of a comparison function not existing
in PostgreSQL was such a driving force, a strong focus was placed on the development of an
algorithm that could serve as an XML comparison

function within an SQL statement.


T
he XML Sort Compare algorithm was not
the
only
attempt to create a method for
comparing XML documents.
One simple
approach
is

to create an algorithm that
is
dependent on all XML nodes having a key. This concept was quickly dismissed, as it

imposes an unrealistic requirement.
The
first realistic

plan was to create a collection of
PostgreSQL functions that made use of
XPath
.
This approach would adhere to one of
the
main
project
goals, which

was to create a comparison method that could exist solely in the
database without the need for another application.

X
P
ath

Using XPath to traverse an XML document,
it was

theorized that
it would be possible to
create
a collection of database functions that could actually compare XML documents.
These functions would make substantial use of
the

PostreSQL xpath function. This function
is defined as follows:

xpath(xpath, xml [, nsarray])



The function xpath evaluates the XPath expression xpath (a text value) against the
XML
value xml.


("PostgreSQL: Documentation: devel: XML Functions", n.d., para
2
).



The function will return an array of the XML nodes that matched the XPath expression.
If
there are no matching nodes or the XPath expression is not valid, an empty array is
returned. The second argument must be a valid XML document.
("PostgreSQL:
Documentation: devel: XML Functions", n.d., para
2
-
3
).


The optional third argument of the
func
tion is an array of namespace mappings.

("PostgreSQL: Documentation: devel: XML
Functions", n.d., para
4
)
.



The following examples make use of the xpath function in PostgreSQL. In these examples,
“Complex” XML Nodes
are
defined

to be
XML tags containing XML tags and “Simple” XML
Nodes
are defined
as XML tags
containing

only

text values.


Select an
XML
C
olumn


Select Complex XML Nod
e(s) based on Name and Location


Select Simple XML Nod
e(s) based on Name and Location


Select XML Node(s) based on Name and Wildcard Location

xml=# select xpath('*/C
', xml_data) from xml_test where id = 1;


xpath

---------------------------------------------------------------------------------------


{<C>VALUE1</C>,<C>VALUE3</C>,<C>VALUE2
</C>,<C>VALUE1</C>,<C>VALUE4</C>,<C>VALUE5</C>}

(1 row)



Select

Value(s) of Simple XML Node(s)


Select an XML
Column containing Attributes


xml=# select xml_data from xml_test where id = 1;


xml_data


-------------------------------------------------------------------------------------------------------------------


<A><B><C>VALUE1</C></B><B><C>VALUE3</C><C>VALUE2</C></B><B><C>VALUE1</C><C>VALUE4</C></B><B><C>VALUE5</C></
B></A>

(1 row)


xml=# select xpath('/A/B', xml_data) from xml_test where id = 1;


xpath

-----------------


{"<B> +


<C>VALUE1</C>+


</B>","<B> +


<C>VALUE3</C>+


<C>VALUE2</C>+


</B>","<B> +


<C>VALUE1</C>+


<C>VALUE4</
C>+


</B>","<B> +


<C>VALUE5</C>+


</B>"}

(1 row)


xml=# select xpath('/A/B/C', xml_data) from xml_test where id = 1;



xpath

---------------------------------------------------------------------------------------


{<C>VALUE1</C>,<C>VALUE3</C>,<C>VALUE2</C>,<C>VALUE1</C>,<C>VALUE4</C>,<C>VALUE5</C>}

(1 row)


xml=# select xpath('*/C/text()', xml_data) from xml_test where id = 1;


xpath

---------------------------------------------


{VALUE1,VALUE3,VALUE2,VALUE1,VALUE4
,VALUE5}

(1 row)


xml=# select xml_data from xml_test where id = 11;


xml_data

------------------
-----------------------------------------------------------------------


<A><B A2="x" A1="y">VALUE2</B><C>VALUE3</C><B>VALUE1</B><B A2="x" A1="z">VALUE2</B></A>

(1 row)



Select an XML Node having a Specific Attribute


Select Value(s) of a Specific Attribute


Difficulties

While XPath provides the ability to access all part
s

of an XML document, knowledge of the
particular document is needed. Without this knowledge, it is impossible to know what
elements to look for in the document.
This violates one of the main goals of the project,
which is to not require user intervention t
o perform the comparison.
For these reasons
, it
was determined that XPath functions alone would not be sufficient to create a
n acceptable

method for comparing XML documents.


XML Schema Definition (XSD)

At this point,
it was

theorized that
a
middleware so
lution
could be developed
that
would
use an XSD to determine the elements that need to be compared for a given XML document.
An XSD is used to structurally validate an XML document. It is similar to a Document Type
Definition but allows for more detailed s
pecification. When validating an XML document
using an XSD, XML nodes and the data they contain are checked for correctness.
(Rubinger,
Monson
-
Haefel, & Burke, 2010, p. 356
-
357).

You measure the correctness of an XML
xml=# select xpath('/*/B[@A2]', xml_data) from xml_test where id = 11;


xpath

--------------
---------------------------------------------------------


{"<B A2=
\
"x
\
" A1=
\
"y
\
">VALUE2</B>","<B A2=
\
"x
\
" A1=
\
"z
\
">VALUE2</B>"}

(1 row)


xml=# select xpath('/*/B/@A2', xml_data) from xml_test where id = 11;


xpath

-------


{x,x}

(1 row)



document by determinin
g two criteria: whether the document is well formed and whether
it is valid.

(Rubinger, Monson
-
Haefel, & Burke, 2010, p. 356
-
357).




Well formed XML documents adhere to the syntax specified in the XML specification. This
includes the presence of only one

root node, the proper use of start and end tags,
the
absence of invalid characters,
and proper attribute declarations.
(Rubinger, Monson
-
Haefel,
& Burke, 2010, p. 356
-
357).


In addition to being well formed, the document must use the
right types of elements and attributes in the correct order and structure.


(Rubinger,
Monson
-
Haefel, & Burke, 2010, p. 356
-
357).

XML documents that
contain the
correct
elements
in the correct order, as
specified
in the XSD
,

are considered valid.
It is important
to note that since validity is dependent on adhering to the XSD, it is only valid in the context
of the application

using the XSD
.
(Rubinger, Monson
-
Haefel, & Burke, 2010, p. 356
-
357).



An XSD can
also
specify “required” and “optional” nodes. A
required node
should always be
included in the XML document. Optional nodes do not always need to appear in the XML
document. Additionally, an XSD can specify the number of times that a node can appear in
an XM
L document. A node can be defined to appear only once in the XML document or as
sequence of nodes with the same name. A sequence can also define the lower and upper
limits (which can be unbounded) on how many times they should appear.


Using this information, the software could dynamically generate SQL containing XPath
expressions particular to the XML documents being compared. The introduction of an XSD
had allowed the comparison algorithm to overcome the difficulties encountered with t
he

XPath approach to XML comparison. The combination of XSD and XPath has the potential to
create a comparison algorithm that is both generic
1

and independent
2
.


Difficulties

It is
still believe
d

that the approach of marrying XPath and XSD could have been

successful
but it was ultimately abandoned for several reasons. First,
it proved to be complicated to
build

a generic algorithm
that could
dynamically build the necessary SQL
.
The algorithm
would need to generate SQL based on the unique nature of the XML
document specified by
the XSD.
Additionally, t
he SQL itself

would have needed to be extremely complicated to
successfully compare even simple XML documents.
Each SQL statement would require
many
XPath
expressions in order to perform the comparison ac
curately. Additionally, as
the XML documents being compared become more complicated, the SQL will become more
complicated and become less and less readable
3
.


The other issues were related to
the
overall goals for the project. This approach would
require
that an XSD be provided for every XML document before any comparisons could be
performed. While this is not an overly strict requirement, as an XSD could be created quite
easily in most situations where one was not already available,
the
preference was to
be



1

Generic is meant to imply that the algorithm can be applied universally to any XML
document.

2

Independent is mea
nt to imply that the algorithm requires no user intervention to
perform the comparison.

3

Readable is meant to describe the ease at which an experienced SQL developer could
analyze the SQL and determine its function and intent.


able to compare documents without this restriction. Finally,
this approach was based on
having an application layer outside of the
database, which
, as stated earlier, was not ideal
.


XML Sort Compare

The XML Sort Compare algorithm is based on a simple
fact
. An XML node is the same if it
has the same:



Name



Value



Attributes



Parent



Children

The comparison of the first
three

bullet items does not present much of a challenge. Name
and Value can be compared using a simple string comparison. The attributes o
f an XML
node are nothing more than Name/Value pairs so, in the end, this type of comparison is not
much different than the first 2 items.

At first glance, however,
the
comparison of the
remaining items is not as straightforward.


The problem with compar
ing the children and parents of an XML node is inherent in the
structure of XML itself. A series of XML nodes (simple or complex, with the former being
less of an issue) are under no restrictions to maintain a specific order. An XSD can specify
the order o
f XML nodes with different names but cannot be used to make any assumptions
about the order of XML nodes with the same name and position in the document.

Therefore, it is inherently difficult to determine if two nodes with the same number of
children are,
in fact, the same because the children could be in a completely different order.
Furthermore
, the grandchildren
4

of the nodes could also be ordered differently.


If an XML node has a different number of children than the node it is bei
ng compared to,
then they are most likely different. A special case worth noting here is the situation where
one XML node is missing an optional node within it while the other document has included
it as an empty node. In this case, two nodes with a differ
ent number of children could
actually be the same.
However, this is
application specific as many applications have rules
regarding whether or not empty optional nodes should appear in the document or not.


The more complicated situation is when t
he two nodes being compared have the same
number of children. The first child node of node 1 could actually correspond the third child
node of node 2 but how can we create a generic algorithm that can take this into
consideration.
T
his problem

has been add
ressed

with what turned out to be an incredibly
simple, yet powerful, technique. By recursively sorting the XML nodes from the bottom up
in a quasi
-
lexicographical order,
it can be assumed

that if two nodes have the same number
of children and they are, in

fact, equal nodes, then
, after the nodes have been sorted,
the
first child of node 1 will equal the first child of node 2, the second child of node 1 will equal
the second child of node 2, and so on.





4

Grandchild is meant to de
scribe a node within a node within a node. That is, C is a
grandchild of A in <A><B><C/></B></A>.


This is no different than any other sorted set of ele
ments. For example, consider the
numeric sets {4,1,3,1} and {1,4,1,3}. The sorted version of both collections is {1,1,3,4},
which makes it obvious that they contain the same data elements. If the sorted collections
had elements with different values at pos
ition two, then we can be sure that the collections
are different. The same holds true for a collection of nodes. If two collections contain the
same nodes, then sorting the collections will put equivalent nodes in the same position in
each collection.


T
his
observation
allowed
for
the creation of
a generic
, independent

algorithm that can
successfully identify whether or not two XML documents are the same. An XML document,
after all, is just an XML node. Therefore, two XML documents are the same if their s
orted
versions have the same:



Name



Attributes



Children

In the general case, it’s not necessary to refer to the value of an XML document, as it is
unlikely that an XML document would contain only simple node.
Parents
have
intentionally
been
excluded from
this list because at the root of the XML document there is no parent.
Additionally, since the algorithm is comparing nodes recursively down the structure after
already having sorted recursively up the structure, there is no need to worry about
whether or n
ot two XML nodes have the same parent. The nature of the algorithm ensures
that you will only ever be comparing two nodes that have the same parent.
This is true
because the comparison starts at the root, which, if the documents are the same, must be

the s
ame node for each document. Then, it moves to the children of the root, which, if the
documents are the same, will be in the same positions in each document. Therefore, we are
always comparing nodes that have the same parent.

Sorting

As described above, i
t is essential to first sort the documents before any comparisons can
be done. Sorting is
done
recursively so that the simple/value nodes within a node are
sorted first.
This

will
be
refer
red

to as recursive bottom
-
up sorting.

The basic concept for this
recursive sort is that in order to sort a node, you must

first

sort
its children, which is a list of nodes. In order to sort a list of nodes, you must first sort each
node in the list, and then you can sort the list. This concept can be seen in the Java co
de
example below.


Once the XML documents have been sorted, they can be compared using the base version of
the XML Sort Compare algorithm.

It is important to note that the sort algorithm and
compare algorithm depend heavily on each other. You cannot comp
are an XML node
without sorting it first and you cannot sort a collection of XML nodes without
some way to
compare the nodes and determine ordering
. This may seem contradictory at first but one
simple aspect allows this to work.



The reason this works is
because of the recursive bottom
-
up sorting. By starting with the
simple nodes at the bottom of the document,
the algorithm
ensure
s

that
the only nodes
being compared are
simple nodes, which are easy to compare because they have no
children, and complex nod
es that have already been sorted. For this reason,
it is possible
to
sort a collection using a comparison algorithm that requires items to be sorted before it can
compare them.

Base Algorithm

The base algorithm is only concerned with determining if two XM
L documents are
different. For this reason, the algorithm stops as soon as the first difference is found. Since
this algorithm is also used for sorting, it is important to be able to distinguish if an XML
node is less than or equal to another node.
The g
re
ater than
operation
can be inferred from
these two operations, as will be seen later in the Python implementation.


The basic concept of the algorithm is to compare the names of the nodes. If they are the
same, then compare the attributes of the nodes. If

the attributes are the same, then
compare the values. If the values are the same, then compare the children. The following
Java code illustrates this example.



The comparison of values and names can be accomplished using Java’s built in String
compariso
n. The attributes are nothing more than name/value pairs and can be compared
by building an ordered string of the pairs and then, again, using Java’s built in
String

comparison. The comparison of the children is slightly more difficult but it is simplified

by
the fact that this algorithm is only concerned with finding the first difference. Therefore, if
the size child collections are different, the nodes are different and we can use the size of the
collections for ordering purposes. If the collections are t
he same size, the algorithm will
recursively compare each child to the child in the same position in the other collection.
Remember, the sorting has guaranteed that we can compare the nodes using their position
if they are, in fact, the same.


It is worth

noting that the actual order that the above items are sorted is not that
important. For example, values could be compared before attributes. The important thing is
that the ordering is consistent so that the assumption can be made that XML nodes will be
i
n the same position in a collection. Earlier,
the ordering was

referred to as quasi
-
lexicographical. This is because the number of children
is actually weighted
slightly higher

than the names and values of the children. The following code is a Python imple
mentation
of the base XML Sort Compare algorithm that uses a slightly different sort order than the
Java version.


In python, the implementation of the
__eq__

and
__lt__
methods
, denoting equal and
larger than, respectively,
is enough to be able to sort

a collection and the __eq__ method can
be used to compare two sorted XML nodes.

Sort Algorithm

The sort algorithm is a slightly modified version of the base algorithm. Although an XSD
cannot specify the ordering of nodes with the same name, users of the T
est Suite may
sometimes find it useful to enforce a strict ordering. Since this would require input from
the user and the Python implementation is intended for use as a database function, only the
Java version contains this modification. The basic concept
is if the two nodes being
compared are “unsortable”, then treat them as equal. Otherwise, the nodes can be
compared using the base algorithm.



The concept of an “unsortable
” node is application specific. For example, imagine a
collection of nodes that need to be ordered by the date the corresponding data was created
in the database. In this case, it’s possible that the user of the Test Suite tool would want to
leave this app
lication specific ordering unchanged. This will allow the comparison to
ensure that this same proprietary ordering is used in each XML document.


The following Java code illustrates this change.



Detail Algorithm

While the base version of the XML Sort

Compare algorithm can effectively identify whether
or not two XML documents are different, some real world applications of the algorithm
require a little bit more

information
. The detail version of the algorithm
is

intended to first
identify if two XML do
cuments are different and, then, if they are different, provide a list of
the differences. This concept proved to be slightly more difficult than first expected but,
although there is some room for improvement, the detail version of the XML Sort Compare
al
gorithm works quite well.


The primary difference in this algorithm is that the entire document needs to be compared
and errors need to be recorded. If the algorithm stopped at the first difference, then the

comparison report would not be complete. This r
equired small changes to the value and
attribute comparisons. These changes can be seen in the below Java code.



The value comparison method now adds an error message when different values are
encountered.



The attribute comparison method now uses th
e intersection and disjunction of the
attribute key sets to determine exactly what is missing and adds the appropriate error
messages.


The method for comparing a list of XML nodes required more extensive changes. The first
change is that the algorithm bre
aks the list down into sub
-
lists. Each sub
-
list only contains

nodes with the same name. This was done to narrow down the problem nodes. For
example, consider

the simple XML document below, which contains
a list of 3 complex
nodes with the names A, B, and C
.


<ROOT>



<A><X/><Y/><Z/></A>



<B><X/><Y/><Z/></B>



<C><X/><Y/><Z/></C>


</ROOT>


This list needs to be compared to a list of 4 complex nodes with the names A, B, C, and D
, as
illustrated in the simple XML document below
.


<ROOT>



<A><X/><Y/><Z/></A
>



<B><X/><Y/><Z/></B>



<C><X/><Y/><Z/></C>

<D><X/><Y/><Z/></D
>


</ROOT>


This is a simplified example but it should be obvious that this is now a simpler problem. A
can be compared to A, B to B, C to C, and it’s immediately apparent that D is missing from
the first list.


The second difference in the list comparison is that fo
r each sub
-
list, matching nodes will
be removed from each list before any comparisons are performed.
The need for this change
can be demonstrated using
another
simple
example
,

Assume two lists
of XML nodes
are
being compared. Each has two elements named A. However, due

to

differences in the
nodes, the sort
placed
the nodes in a different order. The first node in list one matches the
second node in list two exactly.
This can

is illustrated in the two XML documents below.


<ROOT>

<A><X>VALUE1</X><Y>VALUE2</Y></A>


<A><X>VALUE3</X><Y>VALUE4</Y></A>


</ROOT>




<ROOT>

<A><B/><X>VALUE3</X><Y>VALUE4</Y></A>

<A><X>VALUE1</X><Y>VALUE2</Y></A>


</ROOT>


Remember, the sort only guaran
tees to put elements in the same place if the elements
themselves are the same. This makes it easy to identify whether or not a difference exists
but slightly more difficult to actually identify the difference accurately. It is just important
to accurately

identify differences, as it is not identify false differences. In this example, if a
positional comparison is performed on the lists, the wrong nodes will be compared

because
a difference in one of the documents has altered the sort order
. However, by rem
oving the
matching nodes first, that problem is avoided. The first node is removed from list one and
the second node is removed from list two. Now the two nodes that should be the same
,

but
are actually different
,

can be compared.


After matching nodes ar
e removed, the remaining sub
-
lists can use the base algorithms
method for comparing node lists. However, there will be one small difference. If the lists
are the
same
size, an item
-
by
-
item node comparison will still be performed (i.e., node 1 in
sub
-
list 1

is compared to node 1 in sub
-
list 2, etc.). However, there is change to how lists of
different sizes are handled. In this base algorithm, it was as simple as using the size of the
lists to determine which node should be less than the other for sorting pur
poses. Now, the
differences in these lists actually need to be identified.



There are three cases in this situation:

1.

List 1 is empty and List 2 is not

2.

List 2 is empty and List 1 is not

3.

List 1 and List 2 are both not empty

The first two cases are easy to

handle. All of the nodes in the non
-
empty list are missing
from the other list and appropriate error messages need to be generated. The third case is
slightly more complex. This is another situation where it is difficult to know which nodes to
compare. It

cannot be assumed that the extra nodes in the larger list are just missing from
the smaller list. Even if that could be assumed, which nodes are the extra ones? Are the
nodes at the end extra? Or perhaps the nodes at the beginning are extra.


At this poin
t, the detail algorithm does not have an effective method to compare the two
lists. However, it is still possible to provide some insight into the why these two node lists
are

different. This is accomplished by building a set of all qualified node/value st
rings in
each list.


For example, the following node:

<#document>


<A>


<B>


<C>VALUE1</C>


</B>


</A>

<
/
#document>


would be represented as the following set of strings:

/#document/A

/#document/A/B

/#document/A/B/C[VALUE1]



Once the

set of strin
gs is built for each list,

t
he disjunction of these sets can be used to
provide a set of nodes and values that are missing from one list or the other. The Java
implementation for comparing node lists using the detail algorithm is documented be
low.




It was mentioned at the beginning of this section that there was room for improvement in
th
e detail algorithm. There are two

basic problem
s

with this algorithm.



First, w
hen comparing lists of nodes that are the same size, it is still possible t
hat
differences in the nodes have seriously compromised the sort order. In this case, nodes that
should not be compared may be compared. This could result in somewhat misleading error
messages.
It is possible to
take the
same
approach used for non
-
matching

lists but this
ultimately provides much less information because the root of every document is
essentially a mismatched list of one node.
Fortunately
, by only comparing nodes with the
same name
after
first removing matching nodes,
these problems
have
been

mitigated into
virtual non
-
issues. If the lists contain only simple nodes, it is a complete non
-
issue. For
complex nodes, there is a very slight risk of misleading information but there’s actually an
obvious pattern to the results in that case so it is ea
sy to identify.


The second problem exists in the situation where there are a mismatched number of
complex nodes. As discussed, the approach in this situation is to identify unique
node/value strings that exist in one collection but not the other. The pro
blem here is that
it’s possible that a node with the same qualified name and value exists elsewhere in the
collection. In this case, it is possible that a missing node will not appear in the error report.
T
his situation is also greatly mitigated by only co
mparing nodes with the same name and
first removing any matching nodes. Additionally, in a collection of mismatched nodes, it is
unlikely that these are errors are the primary cause for concern.


Sorted

Examples


The following are examples of XML documents sorted using the XML Sort Compare
algorithm. Unsorted documents are on the left and sorted documents are on the right.



Example 1


<#document>


<A>


<B>


<C>VALUE1</C>


</B>


<B>


<C>VALUE3</C>


<C>VALUE2</C>


</B>


<B>


<C>VALUE1</C>


<C>VALUE4</C>


</B>


<B>


<C>VALUE5</C>


</B>


</A>

</#document>


<#document>


<A>


<B>


<C>VALUE1</C>


</B>


<B>


<C>VALUE5</C>


</B>


<B>


<C>VALUE1</C>


<C>VALUE4</C>


</B>


<B>


<C>VALUE2</C>


<C>VALUE3</C>


</B>


</A>

</#document>


This example shows an XML document containing four complex nodes, all named B,
inside of a root node, A. Two of the B nodes contain one child and the other two
contain two children.


The complex nodes with one child are in the correct sort order relative
to each
other, although not in the correct position. That is, the node containing
<C>VALUE1</C> appears before the node containing <C>VALUE5</C>.
However,
they are not in the correct position because one of the complex nodes with one child
appears after co
mplex nodes of the same name with two children in the unsorted
document.


The complex nodes with two children are not in the correct sort order. Additionally,
the simple nodes, C, are not in the correct sort order. That is, VALUE3 is ordered
before VALUE2

in one of the nodes.



Example 2


<#document>


<A>


<B>


<C>VALUE5</C>


</B>


<B>


<C>VALUE3</C>


<C>VALUE2</C>


</B>


<B>


<C>VALUE1</C>


<C>VALUE4</C>


</B>


<B>


<C>VALUE1</C>


</B>


</A>

</#document>


<#document>


<A>


<B>


<C>VALUE1</C>


</B>


<B>


<C>VALUE5</C>


</B>


<B>


<C>VALUE1</C>


<C>VALUE4</C>


</B>


<B>


<C>
VALUE2</C>


<C>VALUE3</C>


</B>


</A>

</#document>


This example builds upon the previous example. The difference here is that the
complex B nodes with one child are now not in sorted order relative to themselves
in the unsort
ed document. That is, VALUE5 appears after VALUE1.


This

document and the document from the previous example are actually the same.
They contain exactly the same information but their unsorted representations
appear different. The sorted representations s
hould make it obvious that they are
the same.



Example 3


<#document>


<A>


<B>


<C>VALUE5</C>


</B>


<B>


<C>VALUE3</C>


<C>VALUE2</C>


</B>


<B>


<C>VALUE1</C>


<C>VALUE4</C
>


</B>


<B>


<C>VALUE1</C>


</B>


<B>


<C>VALUE3</C>


<C>VALUE2</C>


</B>


</A>

</#document>


<#document>


<A>


<B>


<C>VALUE1</C>


</B>


<B>


<C>VALUE5</C>


</B>


<B>


<C>VALUE1</C>


<C>VALUE4</C>


</B>


<B>


<C>VALUE2</C>


<C>VALUE3</C>


</B>


<B>


<C>VALUE2</C>


<C>VALUE3</C>


</B>


</A>

</#document>


This example builds upon the previous example