I've thinked a lot about this but i cannot find a good answer. Why has XML:DB Api the concept of collections and "files" ?
Ok XML is mostly stored in Files right now, so its very near to use a "Filesystem like" Database to store those Documents.
Come on its not a relational DB in which we use different Tables to combine
multiple data with one data, in XML we can write those affiliation in one
XML Tree
But i think this is a break in the XML concept. Why not see the Database as
a whole XML-tree. When i make a query i have to decide on which Collection i
want to make it, this is very limiting.
while writing this mail i had the idea to use namespaces instead of collections for example..... so every namespace has its own B+-Tree
I remember, that i read something on Kimbro Staken's site about future plans
on Xindice and there was a point, something like "rethink collection
concept".
Was this point only made by Kimbro, or is Tom Bradford involved in this idea
too.
has someone a good reason to use collection concept, thinks someone like me?
I'm going to quote a message that I sent to this list the other day in response to Xindice and eXist merging, as I think this should answer your question to a degree.
"There is also the matter of the overall focus of the two projects. Correct me if I'm wrong, but I've always seen eXist as being something of a persistent DOM implementation (like Excelon), where Xindice is more of a document bag (like Tamino). Both implementations have their benefits and their weaknesses, but depending on a person's needs, one will want to choose one over the other. Obviously, these two concepts can be merged with some effort, but is this an effort that needs to be attempted at this time? At this early stage in both projects, I would say no, and leave such a decision for a time when the two have matured in their own right."
Different XML DB's are implemented differently. Some are PDOMs as you suggest, and others (like Tamino and Xindice) are document bags. The goal of the XML:DB API is to not prefer either implementation, but to abstract an interface that supports both concepts. For example, a collection path in the XML:DB API could potential resolve to some branch of a PDOM's superdocument instead of just its root... Or it could refer to a collection of documents in Xindice's hierarchy. I believe it's abstract enough to support both, regardless of the semantics used or the interfaces that are exposed.
P.S.
It would be really interesting if the commercial XML Database software made
by the <dbXML> Group (http://www.dbxml.com) is still using the Collection
Concept. ;-)
The answer to this is 'yes'. Although I've done A LOT of work to evolve dbXML beyond Xindice and into something of a developer-friendly application platform, I've tried to keep the foundations of how and where documents are stored close to the Xindice project. The binary formats are different, the indexing system is different, the APIs are different, but the notion of collection hierarchies and documents within those collections is the same.
The simple reason, I've always believed that this is the correct way to go. Though the concept of tables doesn't translate to an XML DB, the goal of tables is there, and that is to create a logical border between database atoms that have different structures and business purposes. To further clarify this concept, dbXML will also support collection-level constraints (only XML Schemas supported initially).
-- Tom Bradford Chief Technology Officer The dbXML Group http://www.dbxml.com/
