"As far as XML databases, how many are a fact right now? I am curious since I am still in mainly a relational DB world still. I am used to mySQL, SQLAnywhere and MS SQL Server 6.5 / 7.0 and they are all still relational. I am not familiar the latest and greatest, as it takes a while to filter down to agencies with legacy db's."
The above snippet suggest I should make some clarification in regard to XML databases. Currently (as far as I know) there are two types of XML databases. The native and the relational with XML xtensions/functionality. For a definition of 'native' and links to a few products see http://www.rpbourret.com/xml/XMLDatabaseProds.htm#native. The other kind is a relational database that may provide an XML view of the data in the tables and the importing and exporting of XML data where importing involves a schema or DTD that will allow the XML to be mapped to a relational representation (imagine the pain in trying to map DocBook or XSL:FO to tables :) and exporting involves (as you put it) "a decent XML dump" (or so you hope) of the data in the tables. Just one little note before I continue. If you read the definition of 'native' provided in the link you will find out that there are native XML databases built on top of relational databases. They are not theoretically (and I use the word theoretically _cautiously_) the same. A native XML database provide a 'pure' XML only view of its data and is meant to store XML documents exclusively. As I'm sure you are aware relational databases are general purpose solutions. "Also even if MS SQL Server 2000 did manage to do a decent XML dump, many programmers are still using the sql interface and getting a normal result set to deal with. We are in a transitional time which is going to take 3-5 years to achieve so it will be interesting to see how this one rolls over." >3 years is a very long time in the internet universe. I know for a fact that IBM (DB2), Microsoft (SQL2000), and Oracle (8i & 9) have XML support but I can almost guarantee you that by this time next year they won't be the only ones, as a matter of fact, they probably aren't but they are the only ones that I'm aware of. "I am pondering the resultset to XML object representation as a means to generate internal data stores. Using the XML representation as an easy and standard way to handle data while you are dealing with it in Java. I hate building my own custom classes to handle data, easy to do, but time consuming. I find it simpler to use a JDOM or now I am playing with dom4j, a DOM4j data model, where I don't have to build my own custom getter/setter and manulipaltion functions. In the future I suppose using JAXB to generate the XML representation would be the way to go, But it seems to me being able to do it from a Database dump rather than a Schema would also be extremely useful." As a general purpose solution the above to me is the same as smashing everything with the XML hammer. There is a time and place for custom classes and I don't think the 'just make it XML, that'll fix it" paradigm is the answer to all your data handling requirements. Note*: The previous two sentences was a re-statement (from my previous post) of my personal distaste for the lemming effect of new technologies and buzzwords (for additional examples see SOAP and web services). It was re-stated because I'm assuming that you are talking about a general purpose solution to your data handling requirements, on the other hand, if after careful evaluation you have decided (for reason that satisfy _your_ requirements) that an XML representation is the way to go you won't hear a negative peep out of me. As a matter of fact, I would congratulate you and recommend using dom4j as the tool for manipulating XML in Java. My beef with an XML ResultSet is not really with the XML ResultSet in and of itself but its with the XML ResultSet being a component of dom4j (in the dom4j namespace). Even though, in my previous post I argued that an XML ResultSet doesn't ultimately buy you anything, its more an argument that an XML ResultSet doesn't buy dom4j anything. We as developers make our own decisions about what functionality we need or don't need and nothing I say or do should or would change that for developers other than myself. Therefore, if you (the individual developer) need an XML ResultSet in your application write one, just keep it out of dom4j. To me (correct me if I'm wrong James S.) dom4j is a tool for Java developers that programmatically exposes an XML document by providing interfaces that allows one to effortlessly navigate and manipulate an XML document (above and beyond the crap DOM sanctioned by the W3C). Additionally, it allows _developers_ to programmatically create XML documents and manipulate them with the same ease aforementioned. Notice I underlined the word developers, this is because it is my belief that it is the developers responsibility to write code that generate XML not dom4j. dom4j makes it easy to write the code but it shouldn't do it for you. Putting the XML ResultSet in the dom4j namespace is putting functionality into dom4j that I think should exist outside of dom4j. Again, if you (the developer) need an XML ResultSet use dom4j to help you write code that will covert a ResultSet into XML based on your needs. You (the developer) may go so far as making it open-source and available to everyone, who knows, maybe I will one day use it :) "I guess where this is leading me, how are other programmers using dom4j document model. Is it mainly just a step to use before XSLT for many programmers? Are others using it for internal data stores like myself? Or what other use have you found which dom4j makes sense" I predominately use dom4j as a means to get random access to data contained within an XML document. In one application their is a legal questionnaire that some of our clients may need to complete. The questionnaire is relatively large (as forms go) so it was broken down into a series of HTML forms --kind of like an installation wizard (on windows)-- that the client can complete at their leisure because they can save and continue. The MVC pattern was applied to this web-app. The order that the client navigated the form is of importance because future views are dependent on answers given on previous and current views. It so happened the order the views should be viewd was easily expressed in an XML document. The controller servlet uses dom4j to navigate the XML document via XPath and quickly figure out what the next view should be for the user. I have a few more examples but I'm sure you are tired of my rambling by now (at least I am :). Chow Dane Foster Equity Technology Group, Inc http://www.equitytg.com. 954.360.9800 ----- Original Message ----- From: "JSP Insider" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, October 26, 2001 7:52 PM Subject: [dom4j-user] More on JDBC, dom4j and I know these are very general questions, but these are the questions that come to mind in reading the various replies to my last post. Thanks Casey Kochmer [EMAIL PROTECTED] _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp _______________________________________________ dom4j-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dom4j-user _______________________________________________ dom4j-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dom4j-user
