[jdom-interest] Re: jdom-interest digest, Vol 1 #1038 - 13 msgs

[bob mcwhirter]

> One of the issues I can see off the bat is that there is no "standard" way to
> instantiate such a DOMBuilder because there is no method in DocumentBuilder or
> DocumentBuilderFactory to specify a JDBC connection,username and password.   I
> did think of using system properties for this but I wonder if this would be
> some form of API "violation".   The second issue I'm wondering about involves
> XSLT transforms.   Does a transform engine necessarily need an entire document
> in memory to work with or does it use the DOM navigation methods to traverse
> the document?  If XSLT engines copy the DOM to some other internal, in memory
> representation of the document then there really isn't any benefit to storing
> the DOM in a database.  Last but not least, to my knowledge there isn't a
> standard way of "indexing" a collection of DOM objects from various sources, so
> I have the felling that my "DBDOM" object would only provide temporary storage
> of a DOM in the database.

Right off the top of my head, to make it more universally useful, I'd
think the database storage thing would produce simple SAX events.  Then
you could build DOMs, JDOMs, dom4js, or whatnots.  Everything talks
SAX.

Or, create a new Jaxen object model (DatabaseDocNavigator maybe) and
simply work with your 'dom' through xpath extractions.  That might
could work.

Excelon and others also have nifty things using object databases to
simply store persistent versions of the DOM implementations.  So,
you still work with Attributes and Elements, but they get smart-swapped
to disk by the underlying object databases.  

OODBs rock.

	-bob