Re: Review of thoughts on Ad Hoc Queries

[Farrukh Najmi <Farrukh.Najmi@east.sun.com>]

Joe,

I agree with your distilled statements wholeheartedly.

I have never implied that the OQL alternative implies an Object database
implementation. In fact my own implementation uses a relational database.

You are absolutely correct that syntax alternatives chosen has little to do
with implementation choices. They do however vary in ease of use from the
clients perspective and whether they are based on standards. IMHO the custom
XML query interface is most painful during the specification stage. This is
because designing it is not as simple as it seems. The most important criterea
is that it must support queries based on the attributes and methods of RIM. As
Mike Rowley observed in our private conversation (I paraphrase from memory)
"what is the point of a detailed information model if the query mechanism does
not allow use of its attributes and methods".

FWIW, in retrospect I should not have positioned the OQL option as subset of
OQL syntax. It is nothing more than a subset of SQL syntax with limited support
added for calling methods on objects defined in RIM. The methods infact could
almost be viewed as additional attributes. The mapping to SQL is relatively
trivial object-relational mapping exercise. Sadly, the choice of the word
sub-set of OQL brought out a lot of fear.

I have tried to show an open mind to all approaches (without heat or
lightening). This is demonstrated by inviting experts like Mike Rowly and
spending an entire day of the f2f on the XPATH alternative. I then spent the
entire weekend exploring that option further for feasability by actually
defining queries and running them on sample content. The results were posted to
list. Finally, I spent several hours with Mike Rowley yesterday evaluating the
feasability of the approach described by David on the NIST work. We ran out of
time without any conclusions on that approach.

Once again, I am not wed to any approach. I will support whatever choice the
team makes after a rational analysis and due process.

--
Regards,
Farrukh



Joseph Baran wrote:

> -----Original Message-----
> From:   Nieman, Scott [SMTP:Scott.Nieman@NorstanConsulting.com]
> Sent:   Monday, January 08, 2001 10:17 PM
> Subject:        RE: Review of thoughts on Ad Hoc Queries
>
> <<<snip>>>
> I don't see any significant technical difference in a custom query
> syntax vs. constrained OQL or XPATH --- each string needs to be
> parsed and mapped to the underlying query syntax used by a
> given implementation.  It does not prescribe the implementation.
> <<<snip>>> I don't execute the UML model, I map it to a
> programming language...
> <<<snip>>>
>
> Thank you!!!!!
>
> I was beginning to think that I was missing something, since I couldn't
> understand why there seem to be so much serious debate over this issue,
> frequently with more heat than light. I am encouraged to see that I was not
> alone in my interpretation. The majority of the most vociferous arguments,
> both pro and con each alternative, seem to have ignored this point.
>
> In case anyone else still doesn't get it, let me repeat the main point:
>
> +++++++++++++++++++++++++++++++++++++++++++++
> The query syntax DOES NOT prescribe the implementation!
> +++++++++++++++++++++++++++++++++++++++++++++
>
> I don't think we can have a meaningful vote until everyone takes a deep
> breath and lets this sink in.
>
> OR - does anyone actually still believe that the syntax DOES prescribe the
> implementation?
>
> If so, please explain.
>
> If not, lets refrain from arguments which imply that (for example)
>
> OQL syntax implies an object database implementation
> --or--
> XPATH syntax implies a "native" XML database implementation
> --or--
> (whatever syntax) implies (whatever implementation)
>
> Sorry to be so repetitive....
>
> Joe Baran


begin:vcard 
n:Najmi;Farrukh
tel;work:781-442-0703
x-mozilla-html:FALSE
url:www.sun.com
org:Sun Microsystems;Java Software
adr:;;1 Network Dr. MS BUR02-302;Burlington;MA;01803-0902;USA
version:2.1
email;internet:najmi@east.sun.com
fn:Farrukh Najmi
end:vcard