Re: [Xmldb-org-xapi] Features for the next release

[Ronald B. <rpb...@rp...>]

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