XRX: Simple, Elegant, Disruptive

by Dan McCreary

XRX is a new web development architecture that is a milestone in elegant simplicity. XRX stands for:

XForms on the client
REST interfaces
and XQuery on the server

Because XRX uses a single model for data (XML) it avoids the translation complexity of other architectures. The simplicity and elegance of XRX allows developers to focus on other value-added features of web application development and enables non-programmers to create a rich web interaction experience without the need to use procedural programming languages.

Our Request: An Open Mind

Before you begin …take a deep breath. Some of the thoughts expressed in this article may be unsettling, especially for those of you, like me, who have invested years into the learning of procedural programming languages like Java and JavaScript. Those skills may become obsolete if trends, predicted in this article, happen.

This begins a series of articles to describe how one can become an early adopter of this innovative technology. As organizations become more aware, the ability to quickly build rich-client web applications will spread beyond programmers to less technical audiences thus empowering a new class of web application developers. As you proceed, we ask you keep an open mind about how emerging technology will affect IT as well as business end-users.

Use Case for Real Estate Forms

For the last five years, developers have queried their peers “Can we create rich web applications using only XML technologies.” In January 2007, Kurt Cagle encouraged me to use XForms with an open source native XML database/web-server called eXist. EXist developers selected an innovative architecture where every XQuery is directly callable from a REST interface which is exactly what XForms applications need to directly send and receive data to the database. Kurt's suggestion came at a very opportune time. I was working on a project with real-estate transactions that had many associated complex real-estate forms. Traditional methods required approximately 40 inserts into separate tables within a relational database. The use of XForms and eXist resulted in one line of XQuery code:

store(collection, file, data)

That was it. Simple. Elegant.

I was hooked. After spending over 20 years building applications with a variety of procedural languages I found my preferred architecture. I have seen the power of XForms and eXist and can't conceive of returning to my procedural programming ways. It is my hope, that I can convey to you my excitement about this architecture.

This is not the first time an attempt to use a non-translation architecture has been made. In the late '90s tens of millions of dollars funded object-oriented database initiatives with the hope that objects on fat-clients or middle tiers could be stored a queried without translation. However, for all the promises that object-oriented databases made, they lacked standard interfaces and query languages. Further, IT strategists could not overcome their proprietary system lock-in fear. As web-clients expanded, object-oriented databases soon became niche products for specific industries.

It has only in the last year that the combination of XForms, REST and XQuery has piqued interest of application architects trying to optimize software development lifecycles. XRX promises to not only change the role of the software developer but also the role of Subject Matter Experts (SMEs) and Business Analysts.

Proof of Architecture: FireFox and eXist

XForms, REST, and XQuery has matured in an environment that not dominated by a single vendor or product. XRX did not originate in the labs of Silicon Valley which seems to favor traditional brute-force procedural languages like Java and JavaScript. It was rather, championed by a group international software developer’s lead by German, Wolfgang Meier.

This collaboration of developers from IBM, Xerox, Novell and other organizations started by building an impressive XForms extension to FireFox. As people combined these disparate systems with REST interfaces, the overall architectural benefits began to emerge. One should not think that XRX is a mature technology. To date, there are no fully integrated development environments for XRX model and due to vendor and browser support issues; integrated development tools will be slow in coming. However, if you believe that superior application architecture will trump vendor-locking strategies, you should closely examine XRX, even in its current form.

XRX represents the confluence of mature declarative client architecture in XForms and the ability of persistence engines to easily store and query XML datasets. The term declarative identifies XForms as a set of XML elements that tell a client "what" the functionality of an interface is, and leaves the "how" to a standardized software system. With XRX, a single line of XML can declare your desired functionality and allows graphical tools to manipulate these blocks of code resulting in non-programmer tools.

The Translation Pain Chain

To understand the elegant simplicity of XRX, look at the problem of English language translation. Select any passage from any book and enter it into a translation program such as Google Translate. Perform a translation from English to Spanish and from Spanish to German. Then reverse the process by translating the German to Spanish and the Spanish back to the original English. The result will have little resemblance to the original text and will require manual cleanup.

Here is a roundtrip for-step translation using Google Translate of the Gettysburg Address from English to Spanish to German to Spanish and back into English:

Score six fifty-six years ago our fathers came to this continent a new nation, conceived in liberty and dedicated to the idea that all men are created equal.

We are now in the midst of a great civil war, testing whether that nation or any nation so conceived and so dedicated, can long endure. We have mounted a major battlefield in this war. We have come to dedicate a portion of this area and as a final resting place for those who here gave their lives that that nation might live. It is entirely appropriate and proper that we should do this.

But in a broader sense, we can not dedicate-we can not consecrate, we can not on this sacred ground. The brave men, living and dead, have fought enshrined here, far above our poor power to add or subtract. The World little note nor long remember what we say here, but can never forget what they did here. It gives us life and that is not a case pending struggled here, have so far progressed so noble. Rather us to be here dedicated to the great task before us-that from these honored dead we take increased devotion to that cause was, during the last full devotion that we here highly resolve that these deaths are not in vain - that this nation under God, shall have a new birth of freedom and that government of the people by the people and for the people not perish from the earth.

Now compare this process with what web application developers are doing today in a three-tier stack using Java or .Net systems. Each time one writes a web application using standard HTML forms, those key-value pairs in the form must be converted to a set of middle tier objects using an object-oriented language. When the objects are in memory they are translated from the object type libraries to a set of tabular data streams that use the database type libraries and then inserted into the correct order in one or more relational database tables. When a user wants to view or update the data, he/she must gather the data from all of the tables, put it into objects and then translate back to a set of attribute-value pairs and displayed in a web form.

The Disruptive Change of Elegant Simplicity

If you have studied advanced math and physics, you are mostly likely familiar with Maxwell's Equations. James Clerk Maxwell discovered four simple elegant mathematical equations to describe the relationship between electricity and magnetism. Prior to Maxwell’s discovery, the fields of electricity and magnetism were considered separate where each used disparate complex mathematics to show their relationship. Maxwell demonstrated that by looking at problems from a new perspective that many pages of equations can be represented in four simple and elegant equations that can be printed on a T-shirts in a science museum gift shop.

We believe that XRX will do for web development what Maxwells equations did for the study of electricity and magnetism. Briefly stated:

XForms+REST+XQuery = XRX = High ROI for Web Developers

XRX gives developers the luxury of using the same data selection language (XPath) on both the client and server. The same expressions can be used in your MVC bind on the client and in Schematron data validation rules on the server. This however, is not the motivation for migrating to XRX. Declarative techniques that use XML structures tend to accelerate the creation of domain-specific languages (DSLs). DSLs are easier to manage with forms and graphical user interfaces which makes them more useable by SME's and BA's. XRX is the front runner in the declarative revolution and the forces empowering non-programmers. This is not to say that XRX will not have opposition. Vendors selling operating-specific client APIs or SQL products will resist XRX technologies for the foreseeable future. An entire community of AJAX developers has grown up around the lack of declarative technologies in our browsers. But in the long term these opponents will be required to compete against a simpler and superior architecture. Future articles will explore the hidden benefits of the XRX architecture and the challenges XRX presents to large-scale application developers.


In the past, the ability to create rich-client web applications was limited to small groups of highly trained and motivated application developers proficient in procedural scripting languages. XRX and declarative programming will expand this community to include a much larger audience, and with it a shift in power will occur. However, in most organizations this will occur only if IT leadership is interested in empowering business units to solve technically challenging problems and create high-quality user experiences. XRX evangelists are needed to break down the walls between IT and the business. We hope this and future articles will be useful as a tool and as a guide for the faithful.


Jerome Louvel
2008-05-29 01:08:20
Thanks for the great and enthusiastic post! XRX is is an exciting approach indeed.

At the Restlet project, we are also interested in nicely combining all those standards. Beside that, Alex Milowski has already done an integration of Restlet and eXist. If you think Restlet could be a good test bed for your ideas, we would be happy to support you.

Kai Tischler
2008-05-29 04:38:15
What are:
- Schematron data validation rules on the server ?
- SME's and BA's ?
James Orenchak
2008-05-29 12:09:48

I believe that using XForms on the client is simpler and more elegant than using ugly Javascript, but in the IT world, the best solutions don't always win acceptance. I think there are already too many AJAX experts who'll fight like hell to keep people using ugly Javascript for a long time! I hope you're right, because using XForms, REST and XQuery beats the stuffing out of using AJAX, but I have my doubts.

John Turnbull
2008-06-01 10:30:47
Thanks Dan -- great to see this thing named.

Kai -- Schematron is a compact syntax to express rules about the existence of elements, attributes, etc. in an XML document. It's a way of validating XML and offers an alternative to XSchema.

SME: Subject Matter Experts -- the accountant who will use the accounting system, the legal editor who will use legal cross-reference dialog, the engineer who will need the materials properties in a drawing. "The folks who actually do the work."

BA: Business Analyst -- the pre-development software people who tell the developers what the SMEs want.

Asbjørn Ulsberg
2008-06-03 03:23:37
Once XForms become ubiquitous, I believe we'll start seeing solutions like XRX appearing instead of the Ajax approaches currently being used. The only reason I'm not investing any time in XForms is because it isn't available in the browser. It's a wonderful technology, but Ajax is indefinately more available and gives almost the same benefits right now.
Jason Monberg
2008-06-05 19:20:46
Thanks for the post. I've spent the better part of the last year building an application based on XQuery, XHTML, and JavaScript with RESTful leanings. I imagine the comparable acronym to be XRJ (JRX doesn't come off very well).

From experience I agree with the observation that reducing data translation greatly increases the ROI of the development process. Although I continue to encounter quite a bit of ugliness with JavaScript, it plays an important role in my application and fits into the XQuery/XML architecture quite well. There is a lot of room for improvement of course.

Looking forward to digging into the proper XRX architecture as well.

Rick Jelliffe
2008-06-10 04:59:46
You write "Declarative techniques that use XML structures tend to accelerate the creation of domain-specific languages (DSLs)." What is interesting is that the vitality and fecundity of domain-specific markup languages has not, so far, translated into any vitality of domain-specific support languages. Quite the reverse.

Now I don't doubt that it is possible for such ecosystems to emerge (isn't that what the RDF project is attempting), but since a large portion of the XML value proposition is based on the use of COTS and general-purpose tools, I think they will be the exception rather than the rule.

I have two concrete examples. First, the use of Schematron (which operates direct on the markup) and W3C RuleML (when operating on RDF.) The second is that when the gap between the markup and the data model is great enough (e.g. which people variously consider as ugly markup or elegant model-driven development take your pick) then having some kind of domain-specific support (often just an API rather than a whole language) is a reasonable (but regretable?) approach.