cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <>
Subject Xml Schema, Aegis Types, JDom, ...
Date Fri, 20 Feb 2009 23:42:24 GMT
I want to drag a thread of conversation from CXF-2044 to this list.


Aegis, since it's inception in XFire, used JDOM as a representation
for XML Schema. The classes that represent types were invited to
contribute to the schema by directly manipulating the schema in JDom.
This was in turn connected to Jaxen, since Jaxen is the provider of
XPath for JDom.

A motion was made to reduce the dependency on JDom and Jaxen. It came
from the D-OSGi folks, who had technical (and, I think, IP) issues
with the JDom/Jaxen stuff.

So, for 2.2, I wiped out the JDom usage, connecting Aegis directly to
XmlSchema. This is consistent with some overall direction in CXF of
centering on XmlSchema as a representation for, ahem, XML Schema. It
also goes well with Dan and my status as Xml Schema committers and my
status of being the only person with the time and strong stomach to
work on it at the moment.

Brian Relph then reported one of the many rather ugly problems that
existed in the JDom-based universe. It's just really hard to ensure
consistency amongst multiple XML Schema documents by multiple
unrelated classes doing surgery on their individual schemas via JDom.

After some consideration on this list, I want ahead and backported
that work to 2.1.x. What none of us savored in that discussion is that
this: The Aegis API for defining new types is essentially a public
API, and now we've got an incompatible change between 2.1.4 and 2.1.5.

Pro: ok, we have an incompatible change that effects some number of
brave souls who implemented custom types, in return for otherwise
hard-to-achieve fixes for everybody.

Con: it's incompatible, and, not everyone is happy to find that the
tooth fairy has left the XmlSchema API on their pillow overnight.

Dan asks if it's possible to offer any sort of half-way house here. I
doubt it for any level of effort I'm likely to produce really soon.
The Aegis API doesn't just involve the Type building a brand new JDom
Element; rather, it is making any number additions to the overall
schema document.

We have the option of rolling back the port and leaving the bugs. I
can't say that I would approach that effort with great enthusiasm, but
perhaps someone with better SVN chops than mine could tell me how to
do it fairly easily.

View raw message