This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Generally speaking I just leave the DOM in place and create routines that can search and modify it.
The XPath API in recent Java editions can make formulating queries easier.
Joined: Dec 29, 2005
i'll have a look at it (though it seems that it does not support in-memory database mode like hypersonic for sql).
the reason for my needs of a lightweight in-memory database is not only the good support for queries but more to build up xml structures automatically defined by a XSD file and update, delete or create xml structures more comfortably as with DOM building actions (for example with the support of wildcards). if done with DOM building code gets quite tricky.
further more my XSD structures are quite complex and must support different versions.
well lets have a look
Author and all-around good cowpoke
Joined: Mar 22, 2000
o build up xml structures automatically defined by a XSD file and update, delete or create xml structures more comfortably as with DOM building actions (for example with the support of wildcards). if done with DOM building code gets quite tricky.
All I can say to that is YOW! You are undertaking somethinq quite complicated there.
I actually created a program for a customer that did a small part of that problem as part of an on-line editor for XML. It manipulated the DOM but it didn't work from an XSD description.
Instead, I worked out an XML description of what valid structures could contain, plus a representation of the HTML form input field that would be used to get user input for the XML to be created. I suppose this could be done from the XSD but I'm nowhere near comfortable enough with XSD to try it.
Good luck with your project and let us know how it turns out.
Joined: Dec 29, 2005
yes i know, a big task ;)
i already got a solution dynamically generating xml structures with the help of XSOM parser. addressing elements (with wildcards) is done inside custom XML access class with xpath. it can handle optional and choice elements too which are cleaned when finished with working with the document if not set. the stuff works fine for our requirements, but more requirements are coming up and i am getting to the point where i am building a "kind of" xml database. of course this cannot be my core-competence (i want to build business software and no xml database), so i am looking for existing tools.
using binding frameworks like jaxb or xmlbeans is not an option, because it is not flexible on changing versions of XSDs. further more when working with XSDs dynamically it shows up very unhandy.
apart from my need to have an in-memory xml database (-> i do not need persistent data on my harddisk) i really wonder why xml databases still are far away from getting ahead with its relational-brothers. in my point of view, the only reason can be the market dominance of relational databases and legacy apps. i think working with xml is getting very frequent and with the interoperable XML standard there definitely is a killer application for a wide use of xml-databases.