Re: lates RR specs

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

JP,

We will be discussing ad hoc at 10 am EST today. See my comments inline below:

JP Morgenthal wrote:

> Farrukh,
>
> Two points.
>
> 1.  I'd appreciate if you'd add my name to the list of contributors.
>

Name is included, as is Dale's. It was an oversight thanks to your being AWOL in
RR :-) Please join the list and participate. I will be glad to help figure out
the problem of line.

Also I had a disk crash and lost some email so if I have missed anyone else,
please let me know and I will fix the situation.

>
> 2.  I think OQL is overkill. For that matter so is SQL.  I've read the specs
> and I really have a hard time envisioning a situation where complex
> algebraic select statements will be needed to locate and identify the
> information required.

JP as an implementor of RR specs I value your opinion very much but I
respectfully disagree. There is a need to do conjugations of multiple predicates
(that is what ad hoc queries means to me). It was also the first decision tree
fork "Do we need an ad hoc query mechanism". I believe the vast majority of
people I have talked to feel that we do.

Assuming we are doing ad hoc queries, the next fork is what is the query syntax.
The two broad choices are XPATH/XML Query or OQL/SQL. Here the answer is not so
obvious.

Choosing OQL makes it difficult to implement metadata storage in the registry in
an XML store but fits really well with our Object based info model defined by
RIM. If a registry implementation stores metadata in a RDB (such as mine) then a
simple object/relational mapping would map the OQL query to an equivalent SQL
query that could be passed right to the RDB. If a registry implantation stores
metadata in an ODMG compliant Object DB then the query could be passed as is.

On the other side of the coin, choosing XPATH makes it nearly impossible to
implement metadata storage in the registry in a relational database.

So far among the three implementations of RR Tokyo specs all three (including
yours) use a RDB for storing metadata. This small sample favors choosing OQL.

Also note that I believe OQL is more likely to be mappable to XPATH than the
other way around. This is also in favor of OQL since it is easier to support
both forms of storage for metadata with OQL as the standard RR query syntax than
XPATH.

Then there is the issue of the ability to do the kind of queries we need in
either syntax. I believe that OQL can meet all our needs for the most complex
queries (Classification Queries) with relative ease. I do not even know whether
XPATH could do the same. I have asked Eve Maler from Sun who is one of the
principal authors behind XPATH to attend the meeting at 10 am today so she can
help us figure out how XPATH could work. I have also invited Mike Rowley from
Excelon Corp to attend for the same reason.

Finally there is a small issue that we will need to eventually support content
based predicates in ad hoc queries and not all Registry content will be XML.

I think a main issue for OQL is one of fear of the perceived complexity of OQL.
To that end I am working within Sun to get permission to make our query
processor engine for RR OQL be made publicly available in source code form to
anyone. This should help allay the fear of OQL.

As far as XPATH goes, I believe the choice would be much less controversial but
as I said, I am not sure whether it would be the right choice.

>
>
> For ad-hoc functionality I see a requirement for full text indexing with
> regular expression searching and I see a need for some complex filtering.  I
> stress here filtering, because that's effectively what we're doing.  We're
> filtering the superset of all content to locate the ones that match.  This
> also BTW matches with Registry semantics.
>
> Dude, you know I'm pragmatic when it comes to this stuff.  I hope you will
> take my evaluation seriously as I think after reading the specs that using a
> query language for ad-hoc would be sending us down a dangerous path.

JP I value your input and pragmatism. This is not a simple issue where the
answers are clear. I have kept an open mind to all possibilities and sought
expert advice from all quarters within and without Sun that I could get access
to. Bottom line is that this important issue needs to be resolved as a team
decision following due process. At 10 am EST today I encourage all interested to
participate in the f2f meeting (Yuta please post logistics as I believe they are
still missing). We will consider both (all) alternatives on the table but we
need a decision by COB tomorrow.



>
>
> Why don't you post my response to the RR list and see what kind of feedback
> you get?

Done.

>
>
> I'll be in my office tomorrow afternoon if you want to talk.

I will be in RR f2f all day today and tomorrow.

>
>
> JP
>
> -----Original Message-----
> From: Farrukh Najmi
> To: jp.morgenthal@xmls.com
> Sent: 1/3/2001 3:24 PM
> Subject: lates RR specs
>
> --
> Regards,
> Farrukh
>
>  <<RegistryInfoModelv0.53.pdf>>
> <<RegistryServicesSpecificationv0-82.pdf>>  <<Card for Farrukh Najmi>>

--
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