Re: [xml-dev] Achieving object model independence

["Nicolas Lehuen" <nicolas.lehuen@ubicco.com>]

Hi Jim,

I've had a look at the great work you did with Xybrix. I ran it, played a
little bit with the samples and had a look at your APIs. That's pretty
impressive, and your point about why you don't currently support W3C XForm
is pretty interesting.

I notice that you had implemented your own abstraction layer for XML Parsers
(the org.jbrix.xml.XMLDriver class or interface), and implemented it for
Xerces. You should have a look at JAXP, because it is becoming more and more
supported by implementors of XML Parsers and used by applications, so that
you would save a lot of time by supporting JAXP instead of your own
abstraction layer. The first step towards JAXP adoption could simply be to
implement a JAXPXMLDriver, and voilą, you would have immediate support for
dozens (well, maybe only half-dozens) of XML Parsers. The current XMLDriver
solution is sad for me, because I don't use Xerces in my applications, but
another parser through JAXP, which means i'm supposed to load the two
parsers (and no, I don't want to use Xerces, for performance reasons) !

I'm telling you that because we did exactly the same thing : develop our own
XML parser asbtraction layer (now deprecated by JAXP 1.0), our own XML
transformation abstraction layer (now deprecated by TRAX and JAXP 1.1), and
our own XPath expression evaluator abstraction layer (now somewhat
deprecated by Jaxen)... It's the inconvenience of doing things too early :P.

Concerning the fact that you don't want to be dependent of a particular DOM
API (be it W3C DOM, JDOM or dom4j), you could use the Navigator option, as
in Jaxen or Saxpath. This is the least intrusive method.

Your second option is not as practical as the first one for people using
your API, because people can't always guarantee that the DOMs they want to
feed into your API have been built using your factory, and therefore you
won't obtain the expected subclasses. Plus, you have to build subclasses of
non-official classes (i.e. public classes that are marked as "should not be
directly used unless you know what you are doing"), which means that your
subclasses evolution rate will be bound to the evolution rate of the main
product. You certainly don't want to maintain as much different subclasses
version than there are versions in Xerces, even if evolutions in the Xerces
classes will rarely break your own subclasses.

The third method, "wrapper classes", is in fact close to the first one,
instead that the first method features a navigation-oriented API rather than
the tree-oriented API featured in method three. The difference between the
two orientations may be rather slim, but that's not the point here.

The point is that because you don't want to choose a reference DOM, you are
building your own. This is crazy ! Why don't you choose a reference DOM
between W3C DOM, JDOM and dom4j, then build either wrappers or bridges for
others DOMs ? Plus, JDOM and dom4j do already have wrappers for the W3C DOM,
and it's a matter of time before they feature JDOM wrappers for dom4j and
vice versa !

So if you want to have a DOM neutral *navigation* API, you can write your
own, or even reuse the Jaxen one. But if you want a tree-oriented API, make
your choice between W3C DOM, JDOM and dom4j, and use wrappers. But DON'T
build your own set of DOM interfaces !

Regards,
Nicolas Lehuen
Head of R&D - Ubicco
http://www.ubicco.com/

----- Original Message -----
From: "Jim Wissner" <jim@jbrix.org>
To: <xml-dev@lists.xml.org>
Sent: Saturday, November 17, 2001 6:34 AM
Subject: [xml-dev] Achieving object model independence


>
> Hi,
>
> I would like to solicit the list's opinion about the best way to achieve
> object model independence in a library that makes use of XML at a higher
> application level. Specifically, I have a Swing-based implementation of
> xforms, and it is currently based on DOM (Xerces). I would like to change
> it so that it will work not only with Xerces, but with dom4j, JDOM, or any
> other object model.
>
> There are three possibilities I'm currently looking at:
>
> 1. Build a Navigator similar to that in use by Jaxen/Saxpath, only
mutable,
> and pass that around instead of documents/elements/attributes/etc.
>
> 2. Create my own set of basic interfaces that mirror common object model
> components (Document, Element, Attribute), subclass the implementation
> classes of the corresponding dom4j/JDOM/DOM classes, set the appropriate
> factory methods to create instances of the subclasses that implement my
> common interfaces, and return those common interfaces to the rest of my
> library.
>
> I currently use this method with Xerces in order to implement undo/redo of
> DOM mutations, and it is quite effective. Nevertheless this approach makes
> me uneasy because it is dependent on utilizing "nonpublic" components
(that
> is, having to subclass the default implementation classes which, though
> often public in the sense of Java scoping, are sometimes left out of
> documentation and presumably more subject to change than the rest of the
> APIs. Is this true, or am I being overly worrisome?)
>
> 3. Similar to 2 in that I create my own set of basic interfaces that
mirror
> common object model components, but instead of the subclass/factory
scheme,
> make wrappers around the implementation classes of the corresponding
> dom4j/JDOM/DOM classes, and again return those common interfaces to the
> rest of my library.
>
> My questions are:
>
> 1. Is there a better method that I'm overlooking?
>
> 2. How are other people tackling the problem of object model independence
> in cases where higher level libraries might be used in different contexts
> with different object models?
>
> I would very much appreciate any expert advice and insights into this
> problem, and how it can be best approached, and maybe hearing that this is
> an easily (and perhaps already solved) problem...  :)
>
> Many thanks in advance,
> Jim
>
>
> --
> www.jbrix.org
> Open Source Software
> Java - XML - Speech Recognition
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
>