Re: [bdbxml] xmldb like collections?

George Feinberg wrote:
>>> There is no "query all known/open containers" concept.  That would  have
>>> to be built into the implementation of the XML:DB API.
>>> You could either rewrite the query to include hard-coded paths, or
>>> write it to use a variable for the collection/container name, and
>>> put a loop into the query.
>>>
>>
>> Either way it sounds like a fairly complex customization. Currently  
>> we are evaluating xmldb's for their capability before selecting  one, 
>> this is something I would add to my list of trade offs from  the other 
>> xmldb's we've been looking at.
>>
>> Currently, express this trade off list as
>>
>> 1.) useful standard API's.
>>
>> eXist and Xindice:
>> xmldb, webdav, xml-rpc, REST
>>
>> bdbxml:
>> xml-rpc, bdbxml api
>>
>> 2.) database performance:
>>
>> eXist and Xindice:
>> poor scalability in terms of document size.
>>
>> bdbxml:
>> better scalability in terms of document size.
>>
>> 3.) Contextual XQuerying and Collection Hierarchy.
>>
>> eXist:
>> good capability within db for collection context based XQuerying.
>>
>> Xindice:
>> good capability in contextual querying across collections and  
>> multiple databases.
>>
>> bdbxml:
>> no concept of Collection Hierarchy
> 
> 
> 
> This is a purposeful decision.  Because BDB XML is intended to be  tightly
> coupled with an application (it is not a server), the notion of  namespace
> is left flexible, so that the application can choose one that best fits
> its needs.  The implementation of XQuery required that *some* minimal
> namespace support exist, in order to implement fn:collection() and  
> fn:doc()
> in the specification.  That is all that's provided.  

This is quite similar to the XQuery extensions (that have nothing to do 
with xmldb) which both xindice and exist provide. Note exist has quite a 
few extensions to its XQuery implementation which you might find of 
interest:

http://demo.exist-db.org/exist/xquery/functions.xq

> In addition, BDB  XML allows
> the application to entirely take over that namespace, via the  XmlResolver
> interface.

hm, could you elaborate on how an application would utilize this?

> 
> The XML:DB API, as near as I can tell, does not specify the
> scope of a query, other than collection.
> 

Theres two different items here I believe we are discussing.

1.) The idea of a "collection" in XMLDB is a hierarchical directory 
structure (on one or many db's).

exist (1-many)
xmldb:exist://localhost:8080/db/foo/bar
xmldb:exist://localhost:8080/db/foo/bam

xindice(many-many)
xmldb:xindice://localhost:8080/db/foo/bar
xmldb:xindice://localhost:8080/db2/foo/bar

yes, xmldb actually says nothing about multiple db's, its all really 
just a path for the driver to determine which "collection" is the 
context its work in.

2.) The idea of "Collection" represents a "context" for "Services" to 
operate on, and this is where XQuery comes in as a service on a collection:

lets say I have the following collection hierarchy in my xmldb style 
database.

db/
    foo/
       bar/
       bam/

some ad hoc pseudo code might look like:

> Collection col = DatabaseManager.getCollection("xmldb:exist:///db/foo/bar");
> XQueryService service =
>            (XQueryService) col.getService("XQueryService", "1.0");
> 
> service.query("/some/xquery/or/xpath[0]");

this is an XQuery on a collection xmldb:exist:///db/foo/bar

however the following is query now spans *both* bar and bam because they 
are both child collections of xmldb:exist:///db/foo.

>> Collection col = DatabaseManager.getCollection("xmldb:exist:///db/foo");
>> XQueryService service =
>>            (XQueryService) col.getService("XQueryService", "1.0");
>> 
>> service.query("/some/xquery/or/xpath[0]");

> 

So while xmldb doesn't "specify" XQuery collection functions, the API 
can be used to accomplish XQuery query by "context" in an applications 
implementation of "services" like XQueryService on a "Collection".

>>
>>
>>> You mentioned in an earlier message this:
>>>
>>>> This is much different than in xmldb, the concept of collection  is  
>>>> within the database instance itself, there is 1 to many   
>>>> relationship between the db instance and its collections in xmldb.
>>>>
>>>> The challenge I see in equating containers to collections is  that  
>>>> in xmldb an index spans all collections in a db. In bdbxml,  it  
>>>> doesn't seem you could have an index that spans containers.
>>>>
>>
>> I would add to this that Xindice and eXist handle the  implementation 
>> of xmldb slightly differently. Currently eXist works  solely on "1 - 
>> many" relationship between a Database and its  Collections, while 
>> Xindice actually supports a "Many - Many"  relationship where the API 
>> can access multiple db instances on  different url paths while working 
>> with many collections in each db.
> 
> 
> Such variation is why the XML:DB API does not actually specify  behavior 
> to that
> detail.
> 

Yup, your right.

>>
>>> Can you please provide an API reference for Indexes and their  
>>> scope,  as well as query scope in the
>>> XML:DB interface?
>>>
>>
>> In eXist here is a javadoc reference to the xmldb API Database and  
>> Collections API.
>>
>> http://exist.sourceforge.net/api/org/xmldb/api/base/Database.html
>> http://exist.sourceforge.net/api/org/xmldb/api/base/Collection.html
> 
> 
> Here is the public xmldb API:
>     http://xmldb-org.sourceforge.net/xapi/xapi-draft.html
> I can't find anything indicating cross-collection querying
> as a feature.
> 

see first comment above. note as we've both said above, actual 
"*:collection()" function in XQuery have nothing to do with xmldb. Yet, 
both xindice and exist implement them to mean approximately the same 
thing, an xmldb collection.

>>
>> Note: eXist is currently considering working on an new version of  the 
>> xmldb API to accomplish some improvements. Now appears to be  the time 
>> to coordinate with other groups/companies to adapt this  API to Real 
>> World cases.
> 
> 
> If that were done, it'd be good to get some collaborative effort going.
> 
> Regards,
> 
> George

At least then there might be a standard that was actually a standard and 
not just a proof of concept.

-Mark


------------------------------------------
To remove yourself from this list, send an
email to [email protected]