The whole reason this has been left out so far is that there is even a large variation between what it takes to configure a collection when just looking at XML databases.
The way I had been looking at this was as a service attached to a collection. This is how it is implemented in my current implementation but the service is proprietary to dbXML. If we can define a common service then it can be optional to the vendor if they can implement it or not. You actually have this same problem in the relational world as DDL is definitely not interchangable between databases. The problem is an XML database tends to look an awful lot like a file system and people are used to being able to easily create directories on the fly. Depending on the type of XML database it simply may not be that lightweight of an operation or it may require more configuration information then we can provide through a common interface. For instance Tamino requires a schema in their proprietary schema language in order to create a collection. I think about the best we're going to get right now is a common api to create lightweight collections that is optional for all implementations. I'd much rather this be a service then part of the collection interface. Beyond that we're going to need to tackle the whole problem of how XML database schemas are allocated. Lars Martin wrote: > > Hmm, I don't fully understand this. :-/ I see the lot of work to be > done to map from hierarchical structure to flat relational tables and > back. Ok, so far. But where is the difference (not functionally but > basically) between getCollection() and createCollection()? You have > to generate the "same" mapping algorithm. You just write CREATE TABLE > instead of SELECT FROM in your mapping code. Ok, this is written a > little bit too credulously but only because I don't see the difference > you want to point out ... > > On Mon, 30 Apr 2001 10:43:11 -0700 > Tom Bradford <[EMAIL PROTECTED]> wrote: > > Lars Martin wrote: > > > well,as far as I can remember we already noticed the lack of methods > > > for the create of new root collections as well as child collections. > > > To move forward I propose the addition of the following two methods: > > > > While every attempt should be made to create a standard way of producing > > collections, I don't know if any one approach can be considered correct > > for all cases. > > > > For example, an XML:DB driver may be hitting a relational database as > > its data store, and a Collection may be exposed as the result of > > relational mapping between several RDBMS tables. In this case, there is > > no clean way of creating a Collection as there's a lot of mapping and > > other homework that has to be done ahead of time. > > > > One way to approach the problem would be to break the problem down into > > classes, and say that for native and enabled XML databases, there IS a > > clean way to do it, but for mapped databases there isn't, and thus it > > would be up to the vendor of the mapped database driver to figure out > > Collection creation. The problem with that is that it leads to > > inconsistency between the clean way and the various ways mapping vendors > > are implementing it. > > > > Of course, the same applies to dropping Collections. > > -- > ______________________________________________________________________ > Lars Martin mailto:[EMAIL PROTECTED] > SMB GmbH http://www.smb-tec.com > > ---------------------------------------------------------------------- > Post a message: mailto:[EMAIL PROTECTED] > Unsubscribe: mailto:[EMAIL PROTECTED] > Contact adminstrator: mailto:[EMAIL PROTECTED] > Read archived messages: http://archive.xmldb.org/ > ---------------------------------------------------------------------- -- Kimbro Staken The dbXML Project http://www.dbxml.org/ ---------------------------------------------------------------------- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe: mailto:[EMAIL PROTECTED] Contact adminstrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ ----------------------------------------------------------------------
