Re: [xml-dev] Achieving object model independence

[Jim Wissner <jim@jbrix.org>]

Hi Nicolas,

>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.

Thanks for the compliments and thoughtful response.  I'm glad you took the 
time to see what I am working on.

>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.

Yes, I absolutely agree.  I wrote the XMLDriver abstraction before JAXP 
existed, and it is a relic that needs to be rectified, as you mention.  The 
main difficulty is that Xybrix has only one developer right now, and it's 
not paying his bills :/ which means I'm left struggling with making tough 
decisions as to which areas to tackle.  Object model independence and w3c 
xforms compliance are two frequent requests that I receive from 
people.  You've seen the issues around xforms that I've listed, but getting 
rid of this XML driver junk is definitely a necessity...

>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) !

...and this is just why.  I don't want this to be an obstacle to people 
using Xybrix.  It needs to be fixed.

>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.

Very very true.  One decision I've made that I'm happy with is to settle on 
Jaxen for xpath.  I can't say enough about how good this library is, and 
it's small enough that it doesn't exact any kind of penalty (wrt size or 
performance) if someone happens to already have another xpath 
implementation loaded.  So this is a no-brainer to me.

>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.

I've been actually discussing this with Bob McWhirter, who has been very 
helpful and insightful towards this problem.  My main concern with this 
approach, and I'm not sure if it's a valid concern or not, is that it makes 
all of the higher level code a fair bit less readable using a navigator 
than to use object model components.

>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.

Absolutely agree 100%.

>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 !

Maybe this is in fact the way to go.

>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 !

Okay, I'm convinced of this.  The Jaxen navigation API is currently 
read-only, but it's certainly conceivable to create a writable implementation.

Anyway thanks again for the input.  It gives me much to think about.  I 
think there's a solution in here somewhere.

Jim


>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>
> >
>
>
>-----------------------------------------------------------------
>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>

--
www.jbrix.org
Open Source Software
Java - XML - Speech Recognition