[Rets-dev] More about schema overrides

[Matt Lavallee]

Exactly my point, Mr. Rockets.

Jeff, consuming clients wouldn't have to rewrite anything, because they are
already working with the data that the RETS group considers non-standard.  So,
for my purposes, it is a very *easy* transition to say that what used to be the
"ASF" field is now "TotalArea".  The MLS' data hasn't changed, and what I
receive hasn't changed; only the transport mechanism has been modernized.

As I said before and others have raised throughout this conversation, RETS is
first and foremost a transport interface (contract) between systems.  I would
much rather have a reliable data structure than validation rules that add 2-3
years to the MLS' adoption.

The "intent of extensibility" is in no way documented, enforced by the schema,
and impractical to expect adherence by implementations.  Strangely enough, I
pointed out the cleanest way to solve the problem (redefining the type), but you
seem to advocate disparate schemas as though it's a preferable solution to have
a unique interface for each MLS.  Why even have a structured standard at that
point, if the expectation is that each MLS is going to redefine it?  That's
actually worse than standard name lookups.

-Matt

> -----Original Message-----
> From: rets-dev-bounces at rets.org [mailto:rets-dev-bounces at rets.org] On Behalf
> Of dsrockets at gmail.com
> Sent: Sunday, April 29, 2007 12:34 PM
> To: Rets-dev at rets.org
> Subject: Re: [Rets-dev] More about schema overrides
> 
> Why are we even discussing the possibility that a standard should be
> so robust that it can create an all-powerful client that doesnt need
> any external intrevention to take data from one end and bring it over
> to the other?
> 
> I'm back to the concept of RETS being the transport mechanism.  Build
> a second application that takes the payload and does something with it
> - ie a Mapping Agent.  That second application can have the logic on
> data purity.  If my app doesnt mind a varchar 64 PhoneNumber field,
> then so be it.
> 
> I would like to see RETS define the delivery and the stadnrad named
> fields, not the content, form or function of what I can do with that
> data.
> 
> Im gonna have to build a mapping agent anyway, so let the client get
> the data, and let me process it on my own.  You can work for the next
> 10 years on this concept if you want, is it so hard to just break
> transport from end-use?
> 
> On 4/29/07, Jeff Brush <jeffbrush at hotmail.com> wrote:
> >
> > Matt,
> >
> > Doesn't allowing anything into a field/element cause "a whole new level of
> complexity for consuming clients" anyway? Unless your MLS is the only MLS the
> client communicates with, the client code is going to have to code around
> possibly having a "Huge" area value anyway.
> >
> > The original intent behind the extensibility of the proposed payload formats
> is NOT to override element types, but to create new elements in their own
> namespace that provide their own semantics. "Huge" is either a description, if
> it is free form, or a category, if it is an ordered, enumerated type, and in
> either case, deserves its own element. It would not map to '<TotalArea>'.
> >
> > The biggest re-occurring stumbling blocks RETS has had over its lifetime is
> its inability to agree on standardized names and types. Stonewalling by a
> vocal minority has prevented RETS from setting a true data standard, which can
> at least be used as a goal. If your data fields are so completely different
> from the data elements in the 'standard payload', RETS2 encourages an MLS or
> group of MLSs to extent the defined schemas with new elements, create their
> own XML schemas or even develop totally new types of data payloads.
> >
> > Perhaps there needs to be goal of trying to satisfy 80-95% of the data
> requirements of the community instead of unobtainable perfection.
> >
> >
> >
> > Jeffery A. Brush
> > Ronin Technologies, Inc.
> >