RE: Updated Constrained OQL proposal

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

I just noticed that your last message had Bcced the list. The following
response had been sent to you privately by me thinking you had sent me a
private message. So here is a public response.

Mathew please be specific about your issue with classification
definition.

Also I assume that by find*() you mean what I call a focused query
approach. I
defined it as follows:

-----
A focused query is one where the query interface is fixed to do a
specific query
task. A focused query approach pre-supposes what the client would wish
to wish
to search for. Focused queries are defined statically by the Registry
interface.
Focused queries are analogous to calling statically defined methods that
have a
fixed signature.

The current “browse and drill down” queries of the Registry are examples
of
focused queries. The UDDI find_business_by_name query is another example
of a
focused query.
---

The issue I stated regarding focused queries is again cut and pasted:

----
Focused queries have the following problems:
1. They pre-suppose what the client will wish to query since they do not
have
the ability to build complex queries from simpler predicates.
2. They are a maintenance headache since the Registry must support a
separate
interface for each supported query
3. They are not easy to use because the client has to remember separate
query
syntaxes for each query.
Based on the reasons above, a constrained ad hoc query is recommended as
a
requirement for Registry query interface.

-----

In essence focused queries suffer from a combinatorial explosion
problem. Please
correct me if that is not what you meant by find*(). Note that the
current 3
browse and drill down queries are example of focused queries. Focused
queries do
not meet our requirements.

Matthew MacKenzie wrote:

> Farrukh,
> I read your "explorations", and I could argue about them - but to no
end.  I
> don't really like the XPath approach in the final analysis, which I
stated
> below.  On a side note, all I really noticed from your explorations
was that
> something better has to be done for classification definition.
>
> Don't try to discount the point of my message, find*().  If you had
read my
> message all the way to the end you would have seen that I brushed off
XPath.
>
> --
> Matthew MacKenzie
> VP Research & Development
> XML Global Technologies, Inc.
>
> -----Original Message-----
> From: Farrukh Najmi [mailto:Farrukh.Najmi@east.sun.com]
> Sent: January 11, 2001 10:54 AM
> To: Matthew MacKenzie
> Cc: Farrukh Najmi; ebxml-regrep@lists.ebxml.org
> Subject: Re: Updated Constrained OQL proposal
>
> Matthew,
>
> We have looked at XPATH in more detail than you realize.
>
> It seems that you have not read
>
> http://lists.ebxml.org/archives/ebxml-regrep/200101/msg00098.html
>
> Otherwise you would know that we have spent a fair amount of time
exploring
> the
> XPATH option based on my efforts. The following message includes the
fruits
> of
> my own labour in this area with sampel dcouments and sampel XSLT style

> sheets.
>
> http://lists.ebxml.org/archives/ebxml-regrep/200101/msg00041.html
>
> It would improve our signal to noise ratio if you can catch up with
your RR
> reading. Thanks
>
> Matthew MacKenzie wrote:
>
> > <fn>
> > Short answer I forgot to mention is that no there is no such
explicit
> > requirement that the query syntax be mappable to SQL. However I do
see the
> > following requirements:
> >
> > 1. Easy to use and familiar syntax for clients
> > 2. Based on a standard
> > 3. Able to make use of RIM attributes and methods to perform the
kind of
> > queries exemplified in:
> >
> > http://lists.ebxml.org/archives/ebxml-regrep/200101/msg00098.html
> > </fn>
> >
> > I would argue that an XML-specific query language such as XPath
would
> > satisfy 1 & 2, and 3 could be met easily by
> > allowing AND & OR to be used to concatenate XPath statements, e.g.
> >
> > /granddad/dad[1]/kid[@name = "tim"] AND /granddad/dad[2]/kid[@name =

> "bob"]
> >
> > There are freely available XPath implementations that people could
use to
> > achieve the above.  I feel the above is a better solution than using

> > OQL/SQL, but I stil don't like it because it explicity defines the
actual
> > query mechanism.  I would rather see an interface which allows the
> > implementer to select what query/storage mechanism is used.  The
obvious
> > solution to me is to forget this notion of "adhoc queries", and
instead
> > implement more methods on the registry.  Currently, there are a
bunch of
> > get*() methods defined, how about defining a bunch of find*()
methods, and
> > skirt the QL issue like they have done in UDDI.  I know that if
OQL/SQL is
> > used today, we will regret it tomorrow - especically when XML Query
> produces
> > something.
> >
> > <fn>
> > Just curious. How does XML Global store metadata for their registry?

> > </fn>
> >
> > Can't you guess?  We have our own native XML database that uses
QUILT as
> its
> > QL.  This really is immaterial, however - we could easily support
OQL if
> we
> > had to, it is just wrong in my mind, as the metadata is defined in
XML.
> >
> > The find*() approach will certainly scratch your OO itch, so what is
the
> > problem with that idea?
> >
> > :-P
> >
> > Cheers,
> >
> > Matt
> >
> > BTW Sorry about mis-spelling your name.
> >
> > Matthew MacKenzie wrote:
> >
> > > Farrukh,
> > >
> > > Is "mapping to SQL" a requirement of regrep adhoc query?  Your
proposal
> > > stinks of technology bias, and I hope the group recognizes that.
> > >
> > > --
> > > Matthew MacKenzie
> > > VP Research & Development
> > > XML Global Technologies, Inc.
> > >
> > > -----Original Message-----
> > > From: Farrukh Najmi [mailto:Farrukh.Najmi@east.sun.com]
> > > Sent: January 11, 2001 6:15 AM
> > > To: ebxml-regrep@lists.ebxml.org
> > > Subject: Updated Constrained OQL proposal
> > >
> > > Attached is an update to the previous document on my brain dump on
ad
> > > hoc queries.
> > >
> > > The changes are:
> > >
> > > -Much more examples on the types of queries IMHO need to be
supported
> > > -Now uses attribute names rather than accessor method names
wherever
> > > possible
> > > -Added section on mapping OQL to SQL
> > >
> > > I look forward to your comments.
> > >
> > > --
> > > Regards,
> > > Farrukh
> >
> > --
> > Regards,
> > Farrukh
>
> --
> Regards,
> Farrukh

--
Regards,
Farrukh

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