Re: [Xmldb-org-xapi] Features for the next release
Brought to you by:
reinhapa
|
From: Ronald B. <rpb...@rp...> - 2004-06-18 09:01:31
|
Per Nyfelt wrote: > > > 2. Make it possible to do Xpath queries directly on a Resource (and > > > possibly a Collection) without having to go through a XPathQueryService. > > > > What is the reason behind this? And why should the queries be limited to > > XPath? It would make more sense to support XQuery here. > The reasoning is that querying/navigating is such a fundamental thing to an > XML database that the usability would be "greatly improved" if it was > possible to query resources with XPath directly. > > For more info see the discussion on the eXist wiki at > http://wiki.exist-db.org:80/space/ImprovedJavaAPI OK. I understand this now. Some comments: 1) It is application-dependent whether it is useful to query individual documents or collections of documents. An example of a single document query is that I have a document representing a single chapter in a book and I want to find the third section of this chapter. An example of a multi-document query is that I want to find all contracts (documents) in which the plaintiff's lawyer is "Smith". The first query is most naturally done with a call like Resource.query(...). The second is most naturally done with a call like Query.execute(). So it does make sense to want to do queries directly on resources. 2) I see no reason that the query language should be XPath. XQuery is widely implemented and far more powerful than XPath, so it makes more sense to use XQuery queries than XPath queries. (Technically, XML:DB is supposed to be query language independent, which would mean that you would somehow have to indicate which language you were using -- XPath, XQuery, XML-QL, Joe's Special XML Query Language -- but I don't think it would be too bad to just support XQuery.) 3) I'm still not sure if this is a good idea from an architectural point of view. The problem is that XML:DB separates services from resources, and adding a query method to Resource blurs this line. Still it might be a very useful shortcut. > > 1) A very nice change would be to remove the the "centrality" of > > collections. For example, applications currently connect to collections > > and get services from collections. This makes about as much sense as > > connecting to tables or getting SQL statement objects from tables on a > > relational database. It would make a lot more sense to connect to a > > database, get a service from a connection, etc. While this change is > > backwards incompatible, it would greatly improve the API. > > I agree with this to some extent. I too find it awkward to get services from a > Collection instead of the Database. But some services are contextual in > nature such as the query services which apply from the collection where the > service was retrieved and down. This can be handled by associating a > collection with a service but it is not as nice as just getting it right from > the collection IMHO. Maybe we should make it possible to get some core > contextual services directly from a collection through named method calls > such as getXPathService() and move the general, loose typed way of getting > services to the Database class instead? This might take care of the need for > adding query methods to Resources and Collections... I agree that some services are contextual, but I don't think all services should be penalized for this. For example, an XPath service is contextual because one needs to know the context of the XPath query -- a single document, a collection of documents, an entire database. On the other hand, an XQuery service will have much less context, as the target of the query (collection or document) is specified in the query itself. Other services, such as administrative services, take the entire database as their context. To my mind, the cleanest service-based architecture is to connect to the database and get services from the database. If a service needs a particular context (a collection or a resource), then it can be explicitly associated with that context. On the other hand, it is awkward to keep associating context-based services with particular constructs. This is illustrated by the wish to add a query method to Resource. So perhaps the best thing to do is something like the following: 1) Abandon a purely service-based architecture. 2) Integrate particular services where they make the most sense. For example, add a query method to Collection and to Resource. Note that this requires us to commit to a particular query language. 3) Connect to databases, not collections, as connecting to collections is very artificial and unexpected. 4) Create a ServiceFactory interface and let Database, Collection, and Resource all extend it. This will allow some generality. > eXist has defined the following additional services besides XQueryService > mentioned above, which i think we should consider adopting in the API: > > UserManagementService - manages users and permissions I haven't looked at their service, but the idea is good. This is an example of a service that makes sense on the database. > DatabaseInstanceManager - makes it possible to shut down the database. Again, this makes sense on the database. Are there other things this service should do? > IndexQueryService - this one i do not think we should adopt at the moment as > index handling is probably very different between implementations. Agreed. > > 2) Given that JSR 225 (XML Query API for Java) is already in early draft > > release, does it make sense to continue working on the XML:DB API? I > > realize that XQJ is for Java only, but it seems that the marketing power > > of Sun, IBM, and Oracle will mean it is widely adopted. > > I do not know the details of JSR 225. Does it cover everything the XML:DB api > is aiming for? Would it be possible to make our api work together with JSR > 225 and/or vice versa? JSR 225 now has a public draft available, but I haven't had time to read it. The easiest way to think of it is instead of having JDBC and SQL, you have JSR 225 and XQuery. JSR 225 provides ways to connect to the database, execute queries, iterate through results, etc. My guess is that it should be possible to implement JSR 225 on top of XML:DB and vice versa, although they aren't an exact match. The only major difference I see (from looking at the table of contents of the JSR 225 spec) is that XML:DB connects to collections while JSR 225 connects to the database. Minor differences (from a mapping point of view) are things like: 1) JSR 225 has objects for XQuery items and sequences, while XML:DB supports ResourceSets and Resources. The JSR 225 structures are thus more general. 2) JSR 225 supports query preparation while XPathQueryService does not. -- Ron |