[Rets-dev] RETS2 Workgroup Meeting Tuesday 3/14 2PM EST-RQLQuery Language

[Wantao Zhou]

The RETS community is (hopefully) larger than the ones attended the
conference call. :) As Steve pointed out a few times, the whole group
voted in favor of XDMQL.

If there's a problem with DMQL, that's the problem with parsing it,
which the XML based query languages addresses. Moving to RETS2, DMQL
will probably be the last thing in the list that people are "not
familiar" with.

Pegging on SQL also will seriously affect how the language can be
expended or extended, which is already demonstrated by the "ALL IN"
operator. The dilemma is there because this group doesn't define SQL.
Once the query language is set to be a subset of SQL, you got a
self-imposed restriction of the limitations of SQL language itself.

Wantao

-----Original Message-----
From: rets-dev-bounces at rets.org [mailto:rets-dev-bounces at rets.org] On
Behalf Of Dave Dribin
Sent: Wednesday, March 15, 2006 3:33 PM
To: E-mail Rets-Dev
Subject: Re: [Rets-dev] RETS2 Workgroup Meeting Tuesday 3/14 2PM
EST-RQLQuery Language

On Mar 15, 2006, at 4:55 PM, Wantao Zhou wrote:
> Without querying everyone in the RETS community, it's premature to  
> claim
> any opinion as "minority".

It seemed pretty clear for the last couple conference calls that the  
RETS community decided to move forward with RQL.  CRT didn't submit  
RQL for RETS2 out of the blue.  We were *asked* to submit it by the  
desire for RETS2 to have a SQL-like query language, based on our  
experience with our ODBC to RETS bridge.  If RQL does *not* have the  
blessing of the majority of the RETS community, then why am I  
spending CRTs time working on it?

> Also you can't discount any idea just because it's "minority", even  
> if that's the case.

Wantou, I did not discount XDMQL *just* because it was in the  
minority.  I, and others, have given fairly concrete reasons why we  
think that RQL is better than both DMQL and XDMQL.

> Not too long ago, being a "standard language" seems to be the best
> selling point of RQL, but now it is not.

It's *based* on a standard language.  A standard language many, many  
people are familiar with.  I never once said it *was* as standard  
language.  It's nearly a subset of ANSI SQL.  If we get rid of "ALL  
IN", it will be a subset of ANSI SQL.  But a subset of ANSI SQL is  
not the same thing as "being" ANSI SQL.  That's the only point I was  
trying to make.

> I think most of us are familiar with DMQL, so it difficult to claim  
> familiarity is the main reason that we should go RQL.

This isn't about "us" being familiar with DMQL.  It's about "them"  
being familiar with SQL.  By "them" I mean those future RETS  
developers.  The ones that aren't on the mailing list today, but will  
be tomorrow asking questions.  The ones that will be developing next  
generation real estate applications.  The ones that will use RETS as  
part of a transaction.  "They" are already familiar with SQL.  "They"  
have never heard of DMQL, and the first time they look at it they  
cringe.

> Honestly how much time it takes a developer to be
> "familiar" with DMQL? If anything, adding a few more examples to the
> document, that may just do the trick. BNF is great, but examples are
> what "new RETS developers" are looking for.

It's your opinion that adding examples to DMQL is better than  
replacing DMQL.  I respectfully disagree.


> Talking about parsing, yes your XML parser will do the work for  
> you. But
> wasn't that a nice thing?

Parser generators are a nice thing, too.  I think you're making a  
mountain out of a molehill with this whole parsing thing.  I wrote  
the ezRETS SQL to DMQL parser in 175 lines of ANTLR code, and it has  
things that aren't in RQL, like support for COUNT(*), table aliases,  
and ORDER BY:

   <https://code.crt.realtors.org/svn/librets/librets/tags/1.1.0b5/ 
project/librets/src/rets-sql.g>

175 lines of code is a small price to pay for a language that is more  
human friendly.

-Dave

_______________________________________________
Rets-dev mailing list
Rets-dev at rets.org
http://lists.rets.org/mailman/listinfo/rets-dev