Several of us in the XML community have been creating XRX web applications for about a year now and we have a small but quickly growing library of web applications that we tend to reuse over and over for our customers. Many of these web apps have begun life as a simple XML Schema file and have then been transformed from an XML Schema into a full XRX web application using a set of XQuery transformations.
Our goal is to use a Model-Driven-Development style where the applications are generated directly from the XML Schemas. They have all the features of a typical web application: (Create, Read, Update, Delete, Search) and I am now getting to the stage where most of us can create new XRX applications from an simple element-centric XML Schema in about an hour with a little help from some of the tools from the still very rough XRX Wikibook and XRX code samples.
One of the things we find challenging is the need to quickly take these applications and re-purpose them for other customers. Our goal is to be able to take a folder for a web application and just drag it into an "apps" folder just like installing a software package. But we also want the application to be instantly be "registered" by the web site just like an Eclipse plugin is registered. This turns out to be very easy since we can take advantage of the fast XQueries that rely on native XML indexes.
In order to make our applications a little more portable we have stated to create a single XML file that describes the functionality of each XRX application. This file (which we call the app-info.xml file) has much the information necessary for shared web site application services.
What do we mean by web site application services? In the XRX web application portability area we want so of the following behaviors. When I add a new web application to a web site we would like:
- The application and application icon to appear in a site's main applications menu
- The site breadcrumbs to be updated to reflect the application label when you navigate into the application collections
- The "New" menu to allow new items to be created
- The site-wide search functions to include the new items managed by the new application
- The web site's preferences and help files to include the application preferences and help files
- The sites security system to understand standard reader/author/admin roles of the application and allow only the correct roles to change the appropriate files.
What you see is that some of these features are web-site driven and some of them are similar to the functions of an Eclipse plugin. This reflects the fact that many people are using XRX as a web-application development environment. It also reflects the fact that fast keyword index search is now assumed as a built-in function of many XRX applications.
Most importantly, we would like these XRX applications to be portable between any web servers and databases that support XQuery.
It is a long-term dream of ours to be able to build highly portable XRX applications that work seamlessly with any native XML database (as long as these systems support basic XQuery functions and modules). But if databases do support these functions, each vendor should be able to build wrapper XQuery modules that translate the functionality into local function calls that are not part of the XQuery standards today.
Sometimes standards are not adopted by their technical merits alone. The failure of several browser vendors to fully support many w3c standards shows this. But if these standards become embedded in high-value-add solutions, then vendors may have to support them or be left out.
These are all small steps to Kurt Cagle's vision of a set of xDrupal-like web applications that are as rich as Drupal but don't have the constraints of an RDBMS and the architecture problems of document shredding.
A few caveats. The code examples posted are mostly just sample fragments of code that demonstrate the architecture principals of portable XRX applications. We still may be years away from anything that appeals to anyone that can not write XQuery code. XRX will not really move up the hockey stick growth curves till we have our first open source XRX frameworks in place. This will not happen till we get some courageous volunteers that are willing to break from our table-centric past driven by the legacy of punch cards, flat files and RDBMS systems.
We also hope to have some more information on how we plan to extend XQuery to include these functions in the near future.
I should also mention that we are looking for all the help we can get. Please feel free to contact Kurt or myself or others in the XRX community if you would like to help out in any way.