You're right pointing out that there is some impedence mismatch between an application *using* XML and a database storage solution (say Tomcat and XIndice).
But I this is a *feature* not a bug.
I mean: if you wrap XIndice with a JAXP layer, you allow Tomcat to use XIndice as 'XML parser' and you could use it instead of a file system (which might be incredibly useful for clusters of tomcats all using the same configuration served from an XML db!)
The Xindice DOMBuider is already bootstrapped using JAXP, but we allow you to continue bootstrapping with whatever SAX Factory you already had. At the moment, this is only important for documents going into the system, because after the document has reached the database, it doesn't need parsing on the way out. For the most part, none of this is a problem if you use Xindice purely as its architected now, which is in its own VM serving down to a client such as a servlet engine or stand-alone App. It's when you embed Xindice where it becomes a potential problem. At some point, I'd like to see the HTTP Server I wrote replaced, and use Avalon and (maybe) a scaled down version of Tomcat to operate as the server framework. Problem is, I already see this becoming a train wreck.
I don't question the fuctionality, but I question the softare architecture.
What architecture? Based on the variety of how people have used dbXML in the past, I can't even begin to imagine how they're going to employ Xindice, so we need to minimize the potential for damage now, before somebody else's project seriously suffers from it.
For example, providing a webdav interface might allow to make this tomcat-cluster happy, with no need to have a direct JAXP implementation (also JAXP would require you to use RMI for distributed applications, while soap or webdav would do it over the wire).
Oh God! Enough with the WebDAV already. It's not the almighty elixir. :-)
Anyway, besides the implementation details and the examples, my point is: let's XIndice focus on the engine. The applications will come.
The applications are here. I'd like to focus on the engine, but the applications will drive it. Let's not forget why we're here. dbXML already had a fairly large user community before joining the Apache effort. Saying the applications will come negates all of the effort people have put into writing dbXML applications in the past. Sorry, but my loyalty continues to be to those people. They have certainly driven the project to this point, and have done a very good job of it.
There is no agreement in the XML world about what "xml updates" mean or should do. If there is no agreement between you and Kimbro, go figure into the rest of the XML world.
Course there is! But we don't have enough money to play with the W3C, and apparently, we're not 'experts'.
-- Tom Bradford - http://www.tbradford.org Developer - Apache Xindice (Native XML Database) Creator - Project Labrador (XML Object Broker)
