[jdom-interest] Interface-based JDOM

[Tom Bradford]

Brett McLaughlin wrote:
> No, but I'm aware of the goals of JDOM. In other words, if you need an
> implementation of DOM in any form, and will only accept DOM (rather than
> alternate, in our opinion better, functionality), then JDOM is probably
> not the solution you are looking for. That's sort of brutal, but I hope
> shows that we are focused on a specific goal, ease of use. And I argue
> that you simply won't have equal efficiency in DOM, JDOM, or SAX. If
> that was the case, then we wouldn't need both DOM and JDOM, as they
> provide similar functionality. The inefficiency of DOM in certain
> situations is why JDOM exists; I submit that if we couldn't overcome
> those problems with DOM in 1 year of work, your team won't be able to
> solve them either ;-) And I'd also submit that DOM and SAX are
> orthogonal in every way - plus, of course, SAX offers no mutability. So
> I guess that while I'm not clear on the foundation for your goals, I
> still stand on not wanting JDOM to ever implement DOM interfaces.

Personally, I'm not looking for a specific solution.   I'm looking to
provide a set of alternative APIs for people developing with our
product.  If we expose JDOM access, it's likely that we won't go and
rewrite all of our DOM code as JDOM code, but at least that capability
will be there for people developing custom logic for their database
applications.

> And I think we're actually looking at setParent and setDocument as being
> abstracted into a root node class or something similar, which would
> indirectly solve your problems. Yes, if you use implementations,
> factories are required for transparancy. But I'd argue that most
> programmers don't like factories that are "in your face"; in other
> words, that you have to use to do pretty much anything... just creating
> a simple element needs a factory, instead of direct object
> instantiation. So I still find myself (and Jason, as we traded voice
> mails today) on the side of simplicity and avoiding factories, and
> interfaces/implementations.

They don't.  I don't.  In the DOM, it's pretty much a necessity because
of the portability goals of the spec.  It's mainly something one has to
live with to write implementation and language (sorta) portable code.

> I'd agree as long as there is an additional requirement to have DOM
> classes subsume other DOM classes transparantly. But that's not a
> current requirement laid out /clearly/, and even so people tend to use
> their own classes directly, rather than through the interface, and
> therefore introduce dependencies on the impl, not the standard
> interfaces. I certainly would fear the same with JDOM, and therefore a
> loss of code portability.

The main issue there was that DOMImplementation didn't exist in DOM
Level 1, so people were having to instantiate their own Document
instances...  It pretty much follows that if you're gonna do that, you
may as well manually instantiate everything else instead of calling
doc.create<blah>();  It's partly the W3C's fault, partly laziness. 
Either way, it's unfortunate.  You're in a different position though. 
1) You're not trying to create a inter-language standard.  2) You're not
at 1.0 yet.

> ;-) I'd be interested to hear what integration issues you face. For
> example, are interfaces needed in your view strictly to integrate with
> classes that already implement DOM, is it an implementation of utilities
> or your own structure that is needed. Certainly those are all things
> that could be more persuasive towards changes or enhancements, rather
> than just wanting DOM+JDOM support.

It's a mixture of the two.  The interfaces are DOM, but the classes
themselves implement methods specific to de/compressing our bytestreams,
interacting with the originating data store, and performing automatic
external document linking and linking of the results of automated method
execution.  Our DOM (as we'll call it) is a living, breathing entity
that dynamically aggregates itself from varying sources, and as such,
just building frozen in time snapshot of it isn't a good thing.

-- Tom