This page expands on a few ideas for the future evolution of XMLBeans, which is a proposed subproject for either the Jakarta or XML projects -- see XmlBeansProposal. For a detailed explanation of the current version of XMLBeans and how it's different from other Java-XML technologies, see XmlBeansExplanation.

There following themes in XML Beans drive our thinking:

There are two tracks for XMLBeans development I see (i.e., imho) going forward:

TRACK 1 - XML metadata:

XML Beans has a pretty accurate and complete XML Schema API today. It's currently annotated for the purposes of XML<->Java binding. Lots of future work hinges on leveraging this power and generalizing it to be used in other cases.

Here's the track:

1. Generalize our XML Schema support to permit more "annotation" functionality. For example, schemas should be able to be annotated to support different styles of XML<->Java binding. Binding to SQL databases is also of interest.

2. Generalize the schema model so that it is easy to compile XML schema metadata directly from non-xsd sources and support instance data such as

3. Use the functionality above to implement or support standards, depending on demand and progress of the community:

TRACK 2 - XML instance data:

XML Beans has a high-speed approach for dealing with in-memory XML instance data. We can talk about it more elsewhere, but basically by avoiding materializing objects for a large fraction of the entities in the XML infoset, XML Beans can load, save, and store XML very efficiently. Instances can be annotated and support on-demand syncrhonization with other data models. We need to continue to generalize this and bring this functionality forward as well:

1. Currently loading and saving to the store can be done via SAX interfaces. We will remove XMLBeans' LGPL Piccolo dependency before starting open-source work and switch to a pluggable JAXP SAX model.

2. In addition to SAX we want to support JSR 173 (xml pull models) for both plugging in loaders and for extracting information efficiently from instances. That's one of the short-term steps. There may be other pipelines that are of interest in attaching to. We have an interest in high-speed XQuery, for example.

3. Currently XMLBeans supports DOM import and export. However, XMLBeans should be able to efficiently support W3C DOM level 2 "live" on the XML store. The advantage here is that people would be able to use strongly-typed bound Java APIs _and_ DOM on the same instance data without batting an eyelash. [OK, maybe with a coercion or method call or two.]

4. The work above should be generalized to allow efficient implementations of other "live" models on the same XML instances. Examples of candidate alternative APIs, depending on level of need or demand:

5. The opposite problem is also of interest, that is providing a "strongly typed XML view" of non-xml instance data. This brings us a bit further afield from XMLBean's current area, and will be driven by lessons from JSR 222 and other efforts.

Of course in addition to the things listed above there are a number of interesting things that need to be done in the code.

The work listed above is more than a few months of work; over the next year we will need to cut and whittle away at the list. But it's a direction that I think it will bring some tremendous value to the community.

In short, XMLBeans current main strength is that it unifies a few views of both metadata and instance data in a way that programmers have found extremely easy to use.

The main thing we want to do with XML Beans going forward is to apply the those techniques to unify other commonly-used and commonly-desired forms of data. The experience so far with XMLBeans leads us to be optimistic it can be done in a way that is very efficient, accurate, and most of all, very simple for programmers.

XmlBeansRoadMap (last edited 2009-09-20 23:32:43 by localhost)