This can easily be supported by doing what I did with SiXDML. Just add getService(String, String) to the Database class.
Here's the problem with that though. Imagine you have a program that performs service requests in a generic fashion against Collections that are passed to it. Now furthermore, say you have two collections, one is a collection that is relationally mapped, the other that is native. Because of this, the Service may have to be implemented completely differently. When you request a Service of the same name, you'll be getting back the same interface, but with a different underlying implementation.
It's awkward enough that you'd have to query the Collection for its absolute path, and then pass that absolute path to the Database to resolve the Service, but add to that the fact that when you offload Service resolution responsibilities to the Database, you're asking it not only to get a Service, but to get a specific implementation based on the Collection name you're passing to it, which is more responsibility than the Database needs to handle, especially in a system where the collection structure is based on many heterogeneous data sources and implementations.
-- Tom Bradford - http://www.tbradford.org Apache Xindice (Native XML Database) - http://xml.apache.org Project Labrador (Web Services Framework) - http://notdotnet.org
---------------------------------------------------------------------- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe: mailto:[EMAIL PROTECTED] Contact administrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ ----------------------------------------------------------------------
