[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: OOQuery Language

On Fri, 15 Sep 2000, Don Berendsen wrote:
> I'm starting a crude implementation of OQL queries for ozone. I'm using it 
> at the beginning of an XML based report generation engine. The query defines 
> the data content of a report and subsequent XML/XSL/XSLFO documents define 
> the structure and display format of the output. This enables me to define a 
> report through a series of XML/XSL/XSLFO documents without writing any code 
> and then publish the report as XML, PDF or on screen as well as printing it 
> out.

Wouldn't it be easier to to all this in just one environment: XML? I mean,
why not transfering the data content into XML and using XPath (or another XML
query lang when available) to define the content of the report?

> 
> I've chosen OQL since it is reasonably well-known and well-defined, it is 
> much simpler to fit to an OODBMS than SQL, and it has grammers available.
> 
> Although I think the query-kernal is ultimately the way to go, my need to 
> get a product out the door and my limited programming skills preclude me 
> from taking on the implementation of a general solution such as that.
> 
> My crude implementation will focus on the subset of OQL I need and be 
> oriented to the specific structure of our application. For example our query 
> results will be hierarchical composites rather than simple sets or bags.
> 
> Still this work may be useful to others as an example and a basis for their 
> solutions and a more comprehensive one and I'd be glad to pass the work 
> along as an example rather than a tool or framework.

Ok, a starting point would be great. But honestly, I don't believe that a
solution that totally focuses on your requirements will be of that much benefit
for ozone....

> 
> Although I can understand the desire for a more OO query, my brief survey of 
> the genesis of OQL and other attempts at OO query languages convinced me the 
> definition of a robust new OO query language is not a trivial task. Although 
> S.O.D.A. and other alternatives may look interesting, AFAIK they don't have 
> a complete, rigorous definition to base an implementation upon. 
> This is why 
> I chose not to participate in  the earlier request related to implementing 
> S.O.D.A. OQL may not be elegant, truly OO, or computationally complete but 
> it's servicable.
Well, SODA is a totally new approach and it is work in progress. I agree.

Anyway, for me the most important questions is not what is the best OO query
lang (if such thing exists, anyway ;) but: how to evolve ozone so that it meets
the users needs. And it seems that people want descriptive query langs today ;)

All possible query lang solutions are based on the same principles, so I assume
that a generic kernel can be the back-end for all front-ends. Don, I understand
that the development of such a kernel is out of your scope. But what we need
now is not a ready-to-go software but a list of requirements that such a
kernel has to fulfill. Such a specification would be of real benefit for the
ozone development and for your development because it would clearly separate
ozone specific from independent code. If I got this right, Mariusz has
proposed such an architecture in his last mail. IMO his "driver" API is
exactly the API of "my" the query-kernel. What do you think?


Falko
-- 
______________________________________________________________________
Falko Braeutigam                              mailto:falko@smb-tec.com
SMB GmbH                                        http://www.smb-tec.com