RETS Separation Anxiety

1
RETS - Separation Anxiety

• Uncoupling Transport from Payload

2
Topics

• RETS Specification Overview
• Challenges in migration
• A new perspective in development cycle
• Painless migration

3
RETS Two Standards, Too Confusing

• Im Waiting for RETS 2
• Why are you waiting?
• How long will you wait?
• RETS 1 does all I need
• RETS 1 and RETS 2 will never co-exist

4
RETS 1 verse RETS 2

• Two development camps
• Both working on progressing RETS 1 or RETS 2
• Community interest not the focus
• Who decides when one gets cut off?
• Historically false choice that RETS 2 will be
  de facto standard

5
RETS as component specifications

• First step defining the RETS 2 payload as
  simply a RETS Data Schema

• Step Two Change perspective
• RETS 2 consumes the RETS Data Schema
• RETS 2 can consume any Data Schema

6
RETS as component specifications

• First step defining the RETS 2 payload as
  simply a RETS Data Schema

DONE

• Step Two Change perspective
• RETS 2 consumes the RETS Data Schema
• RETS 2 can consume any Data Schema

7
Continue that Thought

• RETS 2 is simply a transport
• Call it such
• SOAP can transport anything
• Transport can change, data remains

8
Where does that leave RETS 1?

• Cant require vendors/MLS to switch to RETS 2
• RETS 1 is simply a transport with payloads
• Decouple them
• HTTP could carry the RETS Data Schema Payload
• SOAP could carry the Compact, Compact Decoded or
  Standard XML
• Drop Standard XML for RETS Data Schema
• Whats it all look like then?

9
RETS Specifications
RETS HTTP Transport
RETS Compact

• Version 1.8

RETS Compact Decoded
10
Obvious Separations

• Many Data Types
• Query are their own payload
• Many Transport Types
• Authentication is transport dependant
• Workgroups are easily identified
• per transport / per data type
• Community Determines which get worked on
• Natural end of life
• Migration Paths are modular

11
Migration

• FTP only MLS services can start pushing RETS Data
  Schema
• Consuming clients change parser not transport
• Adoption of RETS Data Schema by Third Parties
  (Google, Trulia)
• RETS HTTP providers can push towards RETS Data
  Schema
• SOAP can be deployed as identified by the
  community
• Need/function verse mandate
• Other transports can be defined
• REST
• SMTP
• BEEP
• MMS/SMS
• Telepathy

12
Benefits

• The RETS Standard is made up of Specifications
• Can clearly define which specifications are
  required
• Data specification
• Help consolidate all efforts
• GoogleBase, Trulia, Zillow, or the next site de
  jour
• Transport indifferent
• Regionalization
• Removal Concept of Next Great Version
• Transport and Payload Exists Separate
• Definable Workgroups
• Clear Migration
• Incremental
• Unforced

13
Challenges

• Compliance
• Education
• Community
• Industry
• Look Familiar?

14
Summary

• Data is important, transport is interchangeable
• Transports change with time and technology
• RETS 2 naming is deceptive
• Roadblock for Industry adoption
• RETS Data Schema
• Lives on its own
• Transport Independent
• Most valuable parts of RETS
• RETS as Specifications