[Rets-dev] Google Base Housing vs. RETS

Thu Mar 15 13:32:29 CDT 2007

What about standards that do not even have a defined transport-  MISMO or
ACORD.  There is not automated way of retrieving the data.  Each client is
unique to the vendor transport implementation.

A lot of the better known standards such as XML or SOAP and even HTTP are
far more complicated but no one has to look at the standard because there
are tools available to implement.  Maybe that is what is missing.  More
tools to implement RETS.  More source code for implementing servers.  There
are implementation issues like the one vendor that uses numbers for their
system names.  Who ever thought that would be an issue.  There is error in
implementation or misinterpreting the specification.

Of coarse RETS does have its problems.  A SOAP implementation of the
standard has taken about 3 years so far and it is still being worked on.  At
the end of the day vendors are getting the data using RETS 1.x with no
compelling reason to change.

RETS does have that leadership team idea that tries to control the direction
of the standard.  I am not really sure what qualifies someone for that team
other than the typical real estate good ol' boy network.  There does not
seem to be any particular architectural, technical knowledge or industry
experience that is required to be on the team.  They are planning to address
that with the new governance.

I am certainly not a defender of the current state of affairs in RETS.  I
think it is awful bordering on absurd that it has taken so long to develop
the 2.0 standard.  I think it is awful that the authors of the 2.0 standard
either ignored or did not understand the lessons learned in the 1.x
standard.  There are pieces of the 1.x standard that were put in place to
satisfy business requirements and some of those pieces were left out because
the people writing the specification deemed them unnecessary effectively
canceling the vote of adoption.  

The original plan was to have RETS evolve into the 2.0 standard.  Somehow
that turned into throw away RETS 1.x lessons and start a new standard from
scratch so now we have to learn two standards.  At this point we should
probably punt on 2.0 and introduce a SOAP interface on RETS 1.x.  How easy
would it be to do that?  You have a standard WSDL with the RETS API that
matches the RETS 1.x.  You add a METADATA_FORMAT to list what RETS 2.0 calls
payloads and the FORMAT parameter of the query uses one of those PAYLOADS.
What else is 2.0 offering?  You could even offer the FORMAT parameter on
other calls such a metadata for format the response between COMPACT or XML
or ANY FORMAT.  Now suddenly all of the technical knowledge and source code
is preserved and adoption of the RETS SOAP Standard is increased.  It puts
us on a path for more advanced SOAP functionality.

Stuart

  _____  

From: Frank Wanicka [mailto:fwanicka at ezlistmls.com] 
Sent: Thursday, March 15, 2007 10:07 AM
To: 'Stuart Schuessler'; Rets-dev at rets.org
Subject: RE: [Rets-dev] Google Base Housing vs. RETS

"It's no more complicated than any other standard."

Ummm, I think there are a lot of people on the list that would disagree with
that, assuming we are talking about 1.x, since 2.0 is not finalized. In a
vacuum, your statement might be true. But it's failure to build upon
virtually any existing standards means every piece of it needed to be
learned from scratch. Most standards attempt to build on other standards,
which means the true level of complication is less. And 2.0 looks to be
pretty complicated as well. I'm already seeing discussions of RETS Lite on
the list before 2.0 is finalized. That should tell you something.

"Given the high adoption rate apparently there are others that do not think
it is too complicated either."

This is part of the problem. The people on the inside think everything is
going just fine with RETS. Trust me, there are many entities that have not
adopted RETS or been slow to adopt because of its complicated nature. 1.x is
a mess IMO, and 2.0 has been dragging on for years. I attended the New
Orleans meeting (as well as several others prior to that one), and at that
point, the plan was to demo 2.0 at that year's NAR event and have the 2.0
standard finalized 6 months after that. Obviously, that was wildly
optimistic given the speed at which things get accomplished in the RETS
community.

By the time one of your versions gets finalized, it is outdated with regard
to other current industry standards. 1.x was certainly that way, and 2.0 is
heading in the same direction IMO. I don't know what the solution is, but
certainly admitting there is a problem would be a good first step. A good
second step would be to look at what similar technologies/standards people
are flocking to and adopting en masse, and try to learn from them.
Googlebase is obviously not a complete replacement for RETS, but maybe
something could be learned from it. The KISS principle seems to be lacking
in the RETS community.

There are obviously a lot of talented people working on RETS. I truly don't
mean to diminish the work that has been done, but anytime it takes 5 years
to finalize what is basically an Internet standard, there is a problem. 25
years ago in the MLS community, that may be an acceptable amount of time,
but it is not in 2007. 

Is there an official timeline for finalizing 2.0?

_________________
Frank Wanicka
Real Estate Technologies, Inc. 

From: rets-dev-bounces at rets.org [mailto:rets-dev-bounces at rets.org] On Behalf
Of Stuart Schuessler
Sent: Thursday, March 15, 2007 10:33 AM
To: dsrockets at gmail.com; Rets-dev at rets.org
Subject: RE: [Rets-dev] Google Base Housing vs. RETS

>> So why is RETS so complicated again? 

It's no more complicated than any other standard.  Given the high adoption
rate apparently there are others that do not think it is too complicated
either.  Any ideas to make it less complicated are always welcome.  Have you
been to any of the meetings?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rets.org/pipermail/rets-dev/attachments/20070315/8e1539e6/attachment.html