>It should be dynamic and ad hoc while
delivering responses from the query in both the OOdbms >basic data
along with procedures used to manipulate the data for its proper use
(methods).
I agree in most parts, but I am not sure if the
natural language approach is the right thing. Object-dot-notation is both
precise, OO-friendly, and not too difficult to understand for a
non-programmer.
For the most part, the database systems will be
queried by programmers. If non-programmers queries them, they demand graphical
user interfaces (which wasn't common when SQL was invented) anyway.
>While these function might reside and operate
on top of an API. The API should be viewed as the >backbone for the feature
listed above.
Therefore, I suggest that the prime query
language is the language of the API in an object oriented fashion, and
that different graphical and natural language interfaces are implemented on
top of that.
But let's skip the skin and dive into the gore:
what types of operation does it need to support?
I have come up with three kinds, two of which operates on sets (or bags) of objects, and one
that operates on objects:
1) Normal set algebra on objects (joins
etc)
2) Filtering, that is selecting subsets of
objects that meet certain criteria (like WHERE clauses)
3) Following references.
/O