[Rets-dev] More about schema overrides

[Matt Lavallee]

On Tuesday, May 01, 2007 at 1:07 PM, David Terrell wrote:

> The fact of the matter is, you're arguing for a world where Year (integer
> field) can contain things like "last year, I think".

Not "can" contain, "does" contain.  It does.  I don't want to lose that data,
and who are you to say it goes away?

> 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.

How are the MLS vendors not themselves just as keenly aware of the difficulties?
And, mind you, I included everyone who operates as a client with multiple MLSes,
and Sergio agreed in the earlier thread.

> 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.

"Fixing it" implies that it is a task that simply requires directed effort, but
it's not that simple... creating a single, cohesive schema against ALL MLSes and
ALL MLS systems may very well be impossible, particularly when the issue of
_losing_data_ is inherent to the process.

> 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.

The problem is that the new dictionary is enormous.  While RETS 1.x called for a
very limited number of fields to be type-specific (most are text or enums, and a
*choice* few were numeric), RETS 2.0 as-is defines hundreds of very granular
typed fields (e.g., SecureCurrency).

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

I specifically meant 2.0, and I certainly don't think it's any better that it's
4 years old versus 2.  XML Schema passed in 3.

> 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.]

The MLS owns the data, and the MLS makes the input/output decisions (with *some*
enforcement from the vendors).  Even if RETS 2.0 fails and never gets
implemented, my service continues and I still make money.  I, too, am losing
money writing these emails, just like I will if a bad standard becomes my
standard and I'm forced to work with it.  I feel (in the interest of myself and
my MLS) some points need to be made and a lot of people just haven't spoken up.

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

Oh, that's just the tail of the dragon.  It's a question of whether these
proponents would be so vehement for a data validation standard if they weren't
getting paid (as you & I aren't).

-Matt