[Rets-dev] RETS2 Workgroup Meeting Tuesday 3/14 2PMEST-RQLQueryLanguage

[Sergio Del Rio]

Excellent summary, that is pretty much how I remember the discussion going.

Regards,
Sergio Del Rio
Templates 4 Business Inc.

-----Original Message-----
From: rets-dev-bounces at rets.org [mailto:rets-dev-bounces at rets.org] On Behalf
Of Jeff Brush
Sent: March 15, 2006 5:35 PM
To: rets-dev at rets.org
Subject: RE: [Rets-dev] RETS2 Workgroup Meeting Tuesday 3/14
2PMEST-RQLQueryLanguage

Here are the meeting minutes as posted by Bruce:

>Avantia suggested that in the absence of hard data, an experimental 
>implementation might go a > long way toward answering some of these 
>questions, and the group agreed to defer the question of query language 
>until after a more detailed investigation of Xquery. A motion to defer > 
>the decision until after we have hard data on Xquery and a revised DMQL was

>made.
>
>Wantao Zhou of Interealty proposed a subsidiary motion to add an XML 
>representation of DMQL to the two languages mentioned in the motion. He 
>will provide a specification for an XML version > of DMQL3 (Xdmql?) that 
>can also be tested. The subsidiary motion passed 15-0, and the full motion 
>passed 20-0. "

20 people felt more query investigation was needed.
15 people decided to add XDMQL to XQuery and a 'fixed' DMQL to be 
investigated as a potential query language for RETS2.

So the community wasn't much larger than the workgroup call. Many of the 
leading RETS voices were on that call.

Of those three choices:

- XQuery was way too complex to implement at this time with few if any 
benefits. It could be a good fit on the back end though.

- I have not seen a revised DMQL. Developers for the Real Estate industry 
who don't or cannot attends RETS meetings have expressed confusion over 
DMQL. They don't take the time to learn it. After all, it is only slightly 
less obfuscated than Perl with some Lisp thrown in. They'll ask the MLS for 
the right query.

- XDMQL - manually entering a non-trivial XDMQL command is a non-trivial 
task. It is very challenging and quite error prone without a data entry 
tool. Other than removing the fear of not getting the parse grammar "right",

its benefits have yet to be explained.


RQL is another option. It has been successfully implemented and is in use by

real users.

Many users who don't have RETS hardwired into their brains like the idea of 
RQL.


-jb



>From: "Wantao Zhou" <Wantao.Zhou at firstamericanmls.com>
>To: "E-mail Rets-Dev" <rets-dev at rets.org>
>Subject: RE: [Rets-dev] RETS2 Workgroup Meeting Tuesday 3/14 
>2PMEST-RQLQuery	Language
>Date: Wed, 15 Mar 2006 19:03:23 -0500
>
>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
>_______________________________________________
>Rets-dev mailing list
>Rets-dev at rets.org
>http://lists.rets.org/mailman/listinfo/rets-dev


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