What you have described is an implementation detail that should be hidden from the user. Secondly I'm not even sure I understand what it means. However, I do understand that to start a transaction, perform a query or an update I need to first grab some collection object and then grab a service object from it.
So if I grab a the "/db/my_collection/xsl/" collection and obtain a query service or transaction service. Does this mean that I can't use this object to start a transaction or perform a query if I'll be performing operations on the "/db/schemas/" collection?
Yes... and it shouldn't cause confusion because Services as they're implemented at the moment can't be repointed to other Collections. To a Service, the Collection provides context. It may be a starting context for recursive processing, or it may be a singular context... Depends on the nature of, and how the service is implemented. There's nothing stopping someone from implementing a Service that is tied to the root Collection of the database and operates on the database as a whole, but not allowing the possibility of context would be too restrictive contextually, where naming and implementation flexibility are concerned.
-- 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/ ----------------------------------------------------------------------
