[Rets-dev] More about schema overrides

[dbt]

(please try to format to 72 or less characters per line, or replies
get awkward.  Though, I think that the formatting is the least 
awkward thing right now...)

On Tue, May 01, 2007 at 12:36:35PM -0500, Matt Lavallee wrote:
> Paul --
> 
> While it wasn't meant to be personal, there are some conclusions to be drawn
> from the fact that the five or six of us who are "pro-loose" are MLS vendors and
> RETS consumers, while the vocally "pro-strict" have only been yourself and Jeff
> (more about the MLSes in a moment).  Regardless of all else, *I* don't want a
> standard that is going to be a pain for *my* MLS to implement -- pushing
> adoption time to god-knows-when -- and even more of a pain for *me* to consume.
> Undoubtedly the vendors have reached the same conclusion: trying to purify all
> of their clients' data for the sake of RETS 2.0 will be an utter nightmare.

I'm neither a consultant, vendor or user.  One may wonder why I am still
posting to this list at all.

That having been said, one of the goals of RETS has always been proper
data validation.  Go back and read the RETS 1.0 standard -- it's one of
the most complex parts of the spec, and it's seen of the most strenuous
engineering efforts (outside of, perhaps, the SOAP rewrite).

The fact of the matter is, you're arguing for a world where Year (integer
field) can contain things like "last year, I think".  Understand that
part of what RETS was intended to address was the fact that people trying
to use more than one MLS (a concern that doesn't seem to be on your radar
screen AT ALL) basically have to write custom input filters for each 
server.  Some sort of cross-MLS standardization on specific common 
data fields with validation would do wonders for certain segments of the
market.

You're not in that market.  Fine.  Belittling a whole group of people 
based on their mode of business might make you feel better, but it
doesn't change the fact that it's precisely the fact that they're 
dealing with so many different MLSes that help them see these problems.

> Surely, data standardization is a noble goal; but many of us feel that this is
> not the appropriate forum for establishing such policy.  And while those
> participating MLSes see some benefit, they most likely do not appreciate the
> chasm we have to cross to make it a reality anytime soon.  I personally think
> it's of dubious merit even then -- because, as an MLS, _they_ control the data
> regardless.  If they want to change, they can do so without a
> _transport_protocol_ defining the standard.

RETS has always been a transport and a data dictionary.  You're arguing
not against adding a data dictionary, but to remove what is already
there.  Everybody agrees that what is there isn't sufficient.  You 
don't want it.  Paul wants to fix it.  I was never been particularly 
interested in working on fixing it, but that doesn't mean it's not 
an important part of RETS.

> IMHO, there should be a Real Estate Data Standards (REDS) group working on this,
> exclusive of RETS.  RETS-loose would work regardless of their decisions, and
> we'd be done _long_ before such a standard could reach consensus (even among the
> vocal few).

It's called the RETS data dictionary working group, or was when I was 
more active than I am now.  And yes, it's part of RETS.

> I absolutely do not question your credentials with respect to Real Estate
> technology at all (quite the contrary, in fact).  What bothers me most is that
> this standard has been in the oven for two years already, and data validation is
> going to push general adoption out for a minimum of 2 years.  Should it really
> take 5 years for a standard to be implemented?  In light of that, consider how
> quickly we _could_ roll out structured/standard transport!  Within *months* of
> having a final spec, even RETS 1.x could be adapted to speak RETS 2.0, let alone
> the native possibilities from the vendors, which would be as easy to implement
> as Frank's field-mapping tool.

Two years?!  Try more than 10.  Even RETS2, as a project, is 4 years old.

> My issue with consultants -- and, believe me, I understand because I was one --
> is that scope-creep, while inevitable, benefits them personally, and the best
> interests of the collective are not necessarily aligned with their own.  The
> more difficult the specification is to deploy, the more money they will make.
> Moreover, how many consultant members have to position their future gigs based
> on work done here?  To me, that's a conflict of interest, because some
> (potentially-paying) members of the group will likely be afforded more
> consideration than the rest.
> 
> My credentials really shouldn't matter much; particularly since other, smarter
> people with more significant credentials than mine seem to think I'm not the
> crazy on the street corner.

People who want to save money on their database implementation and 
customer service programs and push all the data validation and 
normalization on clients and client vendors have a conflict of interest
too.  This is a commercial standard.  Everybody has a financial 
stake in how it turns out.  [Except me.  In fact, I'm losing money 
by writing this email.  See?  Now I'm better than YOU.]

If your only argument against data validation is a potential conflict 
of interest, I suggest you think harder.