[Rets-dev] RETS2 Workgroup Meeting Tuesday 3/14 2PMEST-RQLQuery
Language
Dave Scott
dms at haplos.com
Wed Mar 15 22:31:06 CST 2006
On Mar 15, 2006, at 7:35 PM, Jeff Brush wrote:
> - XQuery was way too complex to implement at this time with few if
> any benefits.
If part of the intention of RETS2 is to support XML data payloads
other than residential listings (e.g., the OSCRE commercial listings
standard, or MITS , or eRecording, or MISMO), then there is a clear
benefit to XQuery. DMQL, XDMQL, RQL, SQL may be adequate for
requesting RETS payloads; but none of them are well-suited for
querying XML in general. To adequately specify any desired XML
payload, you have to be able to describe hierarchical relationships
in your query language.
Admittedly, implementing XQuery or SQL/XML is complex and probably
not a good choice for the current use of RETS. However, something
like them may be necessary as RETS moves into the transaction space,
and will be necessary if RETS is to become a generic query and
transport mechanism for XML payloads. (My understanding of this
issue may be dated, since it is based upon comments made (and
documents made available) to the OSCRE CIE workgroup by Steve Verba
late last summer.)
Dave
On Mar 15, 2006, at 7:35 PM, Jeff Brush wrote:
> 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
More information about the Rets-dev
mailing list