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

New, Cecil (GEAE) cecil.new at ae.ge.com
Wed Sep 11 13:55:11 PDT 2002

Check out http://xml.apache.org/xindice/

-----Original Message-----
From: Richard Collette [mailto:richard.collette at tritanka.com]
Sent: Wednesday, September 11, 2002 4:29 PM
To: jdom-interest at jdom.org
Subject: [jdom-interest] Re: jdom-interest digest, Vol 1 #1038 - 13 msgs


I'm somewhat new to the list and have been monitoring for a while to get the
feel for things.

This may be slightly off topic so I apologize but I thought at least someone
could guide me in the right direction.

It seems that memory limitations can be a problem when working with large DOM
objects.  I'm wondering if there is any sort of project that is creating a DOM
implementation which uses a database for temporary storage?

The reason I ask is that I have to do a Master's Degree project for a database
class and I thought it would be an interesting task to create a DOM object
which would actually use a database schema to store the nodes.  I just thought
this would be an interesting project which aims at addressing a real world
problem rather than creating another "bookstore" type of project.   I'm aware
that various databases have XML storage capability but I havn't heard of any of
them providing a DOM interface to those stored XML documents.

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.

I know this isn't a simple task for a project but I think if I keep the scope
to storing a document into the database via a supplied InputSource (using a SAX
parser?) or an existing DOM and then being able to Navigate that document as a
"DBDom", without worrying about validation, cacheing, etc. then I'd probably
get a pretty good grade and one never knows if it'll turn into something more
interesting.  Again this is a database project not an XML project for my class.

Any guidence towards existing DOM classes that are similar to what I'm talking
about or thoughts on implementation are greatly appreciated.  I'm not looking
for code to snatch, just an overall picture of what's going on with this type
of thought out there.

To control your jdom-interest membership:

More information about the jdom-interest mailing list