> > I was at a JAXM session at JavaOne on Tuesday when dom4j got a mention -
> > its
> > clear from the direction of JAXM (and JAXP & TRaX) that dom4j can cleanly
> > integrate with these APIs at the 'Source' and 'Result' interfaces in
> > JAXP).
>
> Oh they realized us. Cool. I'm wondering a little.... as JDOM is a JSR...
> Pretty cooooooool.
> :-)
http://java.sun.com/xml/jaxb/
This is Sun's alternative to the technology I've been working on since June '98. Its
about 2 years behind where we are now. I figure
it can only help us by legitimizing our own efforts.
One thing they don't have is the equivalent of our OCM (data model/controler), which
is our alternative to XSL. OCM is the basis for
all our utilities, which perform rather complex XML transformations. (Folk like Simon
St. Laurent tell me that these transformations
are considerably beyond the scope of XSL, which is document rather than data centric.)
I am looking forward to integrating DOM3J and Quick's OCM. This should give us a very
powerful tool indeed.
OCM is designed to work in a multi-threading environment, where the object model is
sharred by multiple processes. So the object
model is always read-only. When changes are needed, it is cloned first and then the
changes are applied to the clone.
The key concept behind OCM is that the root element/object, and any number (but not
always all) child element/attribute/objects are
assigned controler-peers. Currently selection of the peer class can be either on the
basis of model-object class or tag name.
Integration of DOM4J provides a lot more functionality to the peer objects. In
addition, selection of the class for the
peer-controler object can use an xpath expression.
OCM comes in two flavors. Regular and lite. Regular flavor generates SAX events as the
output of the OCM process. This is used for
transforming XML=>XML.
The lite flavor is missing all the helper functions for generating SAX events. This is
used for non-XML output, like XML=>DTD and
XML=>Java.
Adding XML signatures to DOM4J will make the integration with OCM really interesting.
We really need something to help promote OCM
and this might just do it. It is very useful technology, but we currently lack
documentation and good examples (other than our own
utilities).
There is a growing need for a data-centric alternative to XSL. I think OCM can meet
this need. But model/controler, when applied to
tree structures, is a bit of a mess. (Look at swing's JTree for example. Most swing
programmers seem to avoid it, though it is well
worth the effort to learn.)
Bill la Forge
_______________________________________________
dom4j-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dom4j-user
