With all the discussion and excitement surrounding RESO Data Dictionary compliance, I’ve found there’s some remaining confusion about compliance with NAR policy on RESO standards implementation. This post will provide some clarity around the standards and related policy in an effort to eliminate that confusion.
Here is the NAR policy in question:
“The integrity of data is a foundation to the orderly real estate market. The Real Estate Transaction Standards (RETS) provide a vendor-neutral, secure approach to exchanging listing information between the broker and the MLS. In order to ensure that the goal of maintaining an orderly marketplace is maintained, and to further establish REALTOR® information as the trusted data source, MLS organizations owned and operated by associations of REALTORS® will implement the RESO Standards including: the RESO Data Dictionary by January 1, 2016; the RESO Web API by June 30, 2016 and will keep current by implementing new releases of RESO Standards within one (1) year from ratification. Compliance with this requirement can be demonstrated using the Real Estate Standards Organization (RESO) compliance Certification Process. (Amended 11/09/14)”
The RESO standards (a.k.a. Real Estate Transaction Standards or RETS) are made up of two parts: a “transport” and a “payload”. To use a non-technical analogy, think of the transport as a rocket ship that provides the propulsion to carry the payload data up in the capsule at the top. In the case of this policy the transport is the RESO Web API and the payload is the data, in Data Dictionary format. To go back to tech-talk, another analogy would be how the HTTP protocol for the web carries an HTML document as a payload. The takeaway here is that while Data Dictionary has been getting all the attention, there are two parts to RESO standards that must be in compliance – both transport and payload.
What precisely is the Data Dictionary? Currently, when you look at the fields on a RETS server in one MLS market, you might see a “bedrooms” field. If you are a real estate software developer, you would write software which asks for that field. But then you go to an MLS in another market and your software breaks, because that MLS has no “bedrooms” field – it has a “beds” or “bdrms” or “br” field. The Data Dictionary defines a common name and format in which all significant fields can be provided: everyone uses “BedroomsTotal” to refer to the total number of bedrooms. You can still have a local name for a field that is different from how it is named in the Data Dictionary, but when you expose it to a developer via RETS, it’s provided using the same name and in the same format he or she could find in any other MLS.
In the “old days” of RETS, we referred to a single version of RETS (i.e., version 1.7, 1.7.2, or 1.8) that included both a single version of transport and a single version of the data payload. Now, things are different. For example, you can:
- use the transport of RETS 1.7.2 (or 1.8) to provide the RETS 1.7.2 (or 1.8) payload (which wouldn’t pass NAR muster next year) OR
- use the RETS 1.7.2 or 1.8 transport to provide the new Data Dictionary payload. Currently Data Dictionary versions 1.3 is being tested for compliance. The deadline for Data Dictionary compliance is January 1, 2016 OR
- use the new Web API transport to provide a RETS Data Dictionary payload. The deadline for compliance is June 30, 2016.
While you must provide new RESO standards such as the Web API transport within a year of RESO ratification, you can still provide RETS 1.7.2 (or later) transport with the Data Dictionary. There is a “mix-and-match” between certain RESO transports and payloads.
When providing a NAR-policy compliant RETS implementation, you can only mix and match RESO transports and RESO payloads. Even if RESO is capable of testing Data Dictionary compliance separately from any particular transport, one cannot provide a RESO Data Dictionary payload on top of a proprietary API in order to be compliant with the new NAR policy. Remember, the heart of the NAR policy is to provide a “vendor-neutral, secure approach” to exchanging information. There are several proprietary APIs afoot, but no one who writes a RETS client capable of talking to a vendor-neutral RETS server writes it to use a single vendor’s proprietary API. A software vendor may field a proprietary API, but this would be in addition to the RETS server that uses both RESO transport and payload in concert, which must be provided to be compliant with NAR policy.
Mark Lesswing at NAR confirmed this interpretation of NAR policy for me: “I don’t see how compliance for the RESO Data Dictionary can be achieved outside of a RETS Transport. Further, the wording ‘will implement the RESO Standards including: the RESO Data Dictionary’ recognizes that the RESO Data Dictionary is not considered separately from other standards published by RESO such as RETS.” Rodney Gansho (Director, Policy Information) at NAR confirmed it: “That is our understanding of what the Committee and NAR Board of Directors intended.”
Now, this is the long-term intent of the NAR MLS Policy. But, in the short term, the RESO board of directors has determined that “Alternative (non RESO-compliant) Transport protocols can obtain Data Dictionary certification up until 6 months after RESO ratifies the Web API”. Though not specified in the adopted MLS Policy, NAR agrees with this as a short-term compliance goal.
What are the most important “takeaways” from this article?
- The Data Dictionary is getting a lot of press, but RESO standards are about more than just that; the Data Dictionary is just the payload.
- MLSs are also charged with implementing new transports (including RESO’s new Web API) in concert with the Data Dictionary.
- To be compliant with NAR policy, both new transports and payloads must be offered by the MLS within a year of RESO ratification. MLSs can “mix and match” different versions of each part of the RESO standards — the transports and payloads —where they work together.
- MLSs can still also offer older transports and payloads as an option for backwards compatibility, so that developers who have a working RETS solution don’t have to change. How long to do that is a business matter for MLSs and any applicable RETS server provider to decide upon.
Share this post: