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

[Steve Clarke]

>> It seemed pretty clear for the last couple conference calls 
>> that the RETS community decided to move forward with RQL.  

The attendance on the calls is extremely sparse.  We rarely get any
attendance from client vendors at all.  I know that I wasn't attending
the RQL discussions because I'm not really interested in spending my
time redefining the query language.  The Interealty proposal was already
submitted and voted on.  First American is now sending a single
representative to each of the calls for all of our MLS solutions (but
our positions on the issues are coordinated).  As I said, the last
actual VOTE on a query language for RETS 2.0 was for XDMQL2.  Unless
there's been another vote, I'd say that RQL is just a proposal that we
still needs to be voted on.  

Personally, I think it would be more valuable for us to spend our time
on improving the standard field names and solidifying all of the new
concepts introduced with the metadata changes.

>> You and Wantao have said more than once, that RETS2 
>> should have DMQL2 *and* XDMQL2.

I don't think so.  We proposed XDMQL2 because it resolves the ambiguity
problems of DMQL2 without risking any change to the language itself.
And Wantao provided an XSL transform to calm the fears of those
(servers) that still wanted to use their DMQL2 parsers.  I can't believe
I've ever aksed that we support dual query languages.

>> ... concrete reasons why we think that RQL is better than XDMQL.

I think you should post a list of those concrete benefits.  If the
language is truly "better" than I'm sure I can be convinced that it's
worth the extra effort to change.  The only reason I keep hearing is
that it is more 'SQL-like'.  I don't really see that as a big benefit.

Some of the benefits of XDMQL2 are:
1) The ambiguity issues in DMQL2 are resolved because the language is
structured in XML.
2) The language is already familiar in the RETS community.
3) Existing implementations of DMQL2 parsers/translators can still be
used.
4) There is minimal work required to spec out the language.

>> RQL, as currently submitted, is "guaranteed" to be 
>> a 1:1 mapping to DMQL.  Show me one case where this is not true.

Once the RQL proposal has been voted on and adopted, I will take the
time to familiarize myself with it enough to determine if this is true.
Before that it is a waste of time because we have a competing proposal
for a query language that is a much more direct solution to DMQL2's
shortcomings.  I do not consider that XDMQL2 is not more SQL-like a
shortcoming.  

smc



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