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

RE: OOQuery Language



Hi Mariusz,

Thanks very much for your reply.

I'm open to working together in whatever manner that would be mutually 
beneficial on a modular OQL interpreter that would support pluggable 
'drivers' and would like to explore how we might do this. I'm at the very 
beginning of this project and would like to hear your thoughts on the 
interpreter structure and the APIs.

At this time I probably would not attempt to build a generic ozone 'driver' 
on my own but rather implement what was needed on my project.  Hopefully 
that could provide a start on a generic 'driver'.

I've been working with JavaCC and was wondering why you chose SableCC?

My preference is to use JavaCC due to its wide acceptance, support and the 
wide variety of available grammars (e.g. 
http://www.cobase.cs.ucla.edu/pub/javacc/ ). Also I'm using it in some other 
parsing tasks at this time.

The JavaCC OQL grammar I found most promising so far is OQLMulti.jj  
available at http://davis.wpi.edu/dsrg/OOSE/OQL/ . I have no experience 
using this grammar and don't know how it compares to your OQL3.grammar .

Your thoughts?

cheers,

don






>From: Mariusz Nowostawski <mariusz@marni.otago.ac.nz>
>Reply-To: ozone-users@ozone-db.org
>To: ozone-users@ozone-db.org
>Subject: RE: OOQuery Language
>Date: Fri, 15 Sep 2000 14:38:05 +1200 (NZST)
>
>Hi Don,
>
>good luck with your implementation, I am looking forward for a running
>demo.  We have been working on object oriented data modelling and data
>integration from heterogenous sources for some time now. We have not
>used Ozone yet as such, mostly digging into SQL and Spatial
>(Arc/Info) sources. (There is not single partner of ours who could
>provide us with OO data yet  ;o(
>We hvae at:    http://nzdis.otago.ac.nz/projects
>an OQL parser with full OQL EBNF grammar available for download (which is
>based around SableCC parser generator) which you may find useful (the
>quasi grammar from the ODMG OQL 3 book is not correct as you probably
>already noticed). There is little documentation there, but we are happy to
>answer all the questions ;o)  We have also a simple Arc/Info gate which
>enables us to ask OQL queries to spatial file formats (it is in its
>infancy yet though, and we do not redistribute it) and it is an OQL
>interpreter based on the AST generated by the parser, after simplification
>and tree reorganization.
>
>I would be interested in sharing experience in writting an OQL
>interpreter - our current one is not modular and is specialized for
>ArcInfo file formats, however we do have a need for a modular one, to
>which we can plug different "native" drivers, like JDBC-based,
>Arc/Info-based, Ozone-based etc.  Maybe we could exchange ideas and built
>common API for the interpreter to make it more pluggable, and then you can
>finish it up with Ozone "driver" and we could make JDBC or/and Arc/Info
>"drivers" for it, what do you think?  (JDBC I mean a "driver" which takes
>requests from the interpreter as a method calls via uniform API and
>translates them into JDBC calls on some SQL-ba`sed data, wraps results
>into objects/sets/bags/collections and returns back to the calling
>interpreter).  What do others think?
>
>
>regards
>Mariusz
>
>
>
>
>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.
> >
> > 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.
> >
> > 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.
> >
> > don
> >
> > >
> > >On Thu, 14 Sep 2000, Knapp, Robert \(CAP, CMC\) wrote:
> > > > >%_Falko,
> > > > 	From what I'm reading here (and I really just skimmed it)
> > > > it sounds like you object (and your reasons are sound) to
> > > > having OOQL built into Ozone.
> > >Do you mean ODMG OQL? I assume yes.
> > >
> > > > How about building an OOQL to Ozone bridge, that would do all of the
> > > > by hand work?
> > > >
> > > > Here's my example.  I'm working on a Laboratory Information 
>Management
> > > > System, one of the basic requirements for most labs is a SQL-like
> > >language
> > > > so that they can print reports and such.
> > >I understand this requirement. What about a XML interface for reports 
>and
> > >such?
> > >
> > > > If someone were to build a bridge(separate from ozone) that accepted
> > > > queries and spit back collections, would that be an acceptable 
>solution?
> > >To
> > > > both you and the people in need of ooql?
> > >In general, even OQL is "acceptable" for me. I just said that am not 
>going
> > >to
> > >work on OQL support for ozone now or later.
> > >
> > > >
> > > > I've been following this list for a while, and it looks like
> > > > Ozone suits 75%+ of our needs(which to date seems to
> > > > be more than anyone else!),
> > >:)
> > >
> > > > so I'd like to try and figure
> > > > out some way to make everyone happy here.
> > >Thank you, Rob. These are very good points.
> > >
> > >Conclusion:
> > >- descriptive query lang(s) is(are) needed
> > >
> > >- an independent query-kernel seems a good way to implement the pure 
>query
> > >functionality
> > >
> > >- different fron-ends can use this kernel to provide the different APIs
> > >(OQL,
> > >SODA, 'XQL')
> > >
> > >
> > >Falko
> > 
>_________________________________________________________________________
> > Get Your Private, Free E-mail from MSN Hotmail at 
>http://www.hotmail.com.
> >
> > Share information about yourself, create your own public profile at
> > http://profiles.msn.com.
> >
>
>--
>   _  _   _  _   _    _
>  / `'/ /-/ / ' / \/ /
>~~~~~~~~~~~~~~~~~~~~~~
>--
>Mariusz Nowostawski    Email: mariusz@rakiura.org   Web: www.rakiura.org
>Rakiura - The Glowing Sky, Evolution Research & Software Agents at Large
>Phone work: +64 3 479 8317  home: +64 3 473 8693     Fax: +64 3 479 8311
>

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.