The XOperator

            by Living Pages Research GmbH, Munich
                         2004, January 20
                         2009, October 12



1. What is the XOperator?

The XOperator implements a simple XML Algebra used to compare and merge XML
documents. It is implemented in Java and can be used as a standalone command
line tool or as a library included in Java projects.
XOperator was developed by Living Pages Research GmbH as part of the Ercato
project.
XOperator is free for noncommercial use as specified in the file "Copyright.txt".


2. Why XML Algebra? - The Ercato concept

The flexibility and no-limits expandability required by modern software
projects calls for techniques beyond the classical object oriented approaches
common in J2EE software development. To answer this challenge, Living Pages
Research has developed the Ercato Engine based on the principle of
"Thing oriented programming". Real world "things" are represented as XML
documents (called ercatons) containing both data and methods. To achieve
inheritance as in object oriented programming, a flexible means to manipulate
complex XML structures was required. Calculating differences between XML
documents and adding deltas to other documents is done by XOperator.
XOperator works on complex structures that are not defined by any XML Schema
or DTD.

The XOperator is capable of representing object-oriented inheritance as
algebraic operations working on XML-DOM trees.

Details of the Ercato concept have been presented at conferences like
Net.ObjectDays 2003 and iX'Conference in 2003 and in articles, e.g., published
in the German iX 02/2004 magazine.

More information is available at http://www.living-pages.de


3. Using XOperator

a) Installation:

After retrieving the xop.jar file, check the JAR's signature. Valid versions
must be signed with an officially signed certificate for Living Pages
Research GmbH. Now, just copy xop.jar into your classpath or current directory.

In JDK version 1.4 or later, XOperator requires no other libraries. In older
distributions XML libraries and the JAXP environment must be available in the
classpath.

b) Usage:
Entering on the command line:

	java -jar xop.jar

will show a short usage text. The input files are passed as arguments separated
by a " - " or " + " operator, the result is written to stdout. Much more complex
expressions are supported. In the following, the command line prefix

	alias xop="java -jar xop.jar"
	
is assumed. When used as a java library, XOperator can also operate on DOM nodes
instead of whole documents.
A complete documentation including all elements and attributes used is provided
as Java ApiDoc.


4. Examples

a) new - old

This simple example demonstrates the general usage and the representation of
changes by XOperator.
Invoke the example with

	xop new.xml - old.xml > changes.xml
or
	xop changes.xml = new.xml - old.xml

changes.xml now lists the changes made to old.xml to obtain new.xml. Unchanged
elements carry the attribute erc:inherit="expand". Newly introduced elements or
attributes are simply listed in the position they appeared in. Deleted elements
are represented by their element tags with the attribute erc:inherit="delete".
Removed attributes have their contents replaced by the value
"erc:inherit=delete".

b) books + addthis

This example shows the addition of a new attribute to a list of elements.

	xop booklist.xml = books.xml - addthis.xml

The attribute erc:inherited-as="vector" causes this element to be applied to
all existing occurrences of a matching element. If no matching element is found,
no changes will be made.

c) tiger + whiskers

This example demonstrates XOperator application to SVG images. The file
tiger.svg contains the well-known vector image of a tiger. In nowhiskers.svg
the image has been changed by removing the tiger's whiskers.
As SVG consists of very similar entries, optimal matching of nodes is complicated.
XOperator can be told to identify matching nodes by attributes that uniquely
identify elements. In SVG the "id" attribute serves this task.
A command line option "-byname http://www.w3.org/2000/svg id" instructs
XOperator to use the "id" attribute in the default SVG namespace to identify
elements. Check for namespace declarations within documents first. They differ...
The command

	xop -byname http://www.w3.org/2000/svg id tiger.svg - nowhiskers.svg > whiskers.svg

extracts the differences (in this case the whiskers).
As SVG is a sufficiently simple format this new file can be directly viewed
in a SVG viewer.
Adding the differences to the "shaved" tiger will restore the original image:

	xop -byname http://www.w3.org/2000/svg id whiskers.svg + nowhiskers.svg > fulltiger.svg

fulltiger.svg now contains the complete image. You may which verify that

	xop -byname http://www.w3.org/2000/svg id ((tiger.svg - nowhiskers.svg) + nowhiskers.svg) == tiger.svg)

Note that in general, if two different changes have been made, both may be merged this
way (example files not provided):

	xop merged.xml = (new2.xml - old.xml) + new1.xml

	
Enjoy using XOperator.