Recently, I became worried about the state of the RETS standard. It seemed like companies left and right were promoting proprietary APIs for moving MLS data. These proprietary APIs are ways of moving more kinds of MLS data than RETS can currently move (i.e. contacts and saved searches) and could move the data more easily than RETS. But I was hearing from developers that they didn’t like the idea of having to develop their software both to use RETS and proprietary APIs as well. I posted about this on an industry blog, MLS Tesseract, and even more developers registered their concern about having to develop to multiple APIs. Rob Overman posted a great blog about this too, clarifying the debate. But the companies working on the proprietary APIs had their own concerns which I could appreciate – saying that some third developers wanted access to information that RETS couldn’t accommodate and that they had to do something. But I think RESO can rise to meet that challenge, and do so faster than the proprietary APIs can gain significant adoption. The RETS standards process is moving faster than ever, and the process seems like it will continue to accelerate.
Over the past few years it is true that RETS progress had slowed – only minor, incremental changes had been made while RESO incorporated and important steps like putting intellectual property policy in place and getting funded were taking a lot of attention. But those distracting tasks are done, and the group is focused on making up for lost time. Now, I have trust that Rob Larson will lead the “data dictionary” work group to create ways of moving all kinds of data, and do so in a timely way. I trust Scott Petronis will lead the “transport” workgroup to document a new and better way of accessing that data quickly, and meet their commitments. And, if for some reason these groups were to lose momentum, I have trust that the board of directors – full of MLS executives and other industry leaders – would notice and take action to regain speed.
RESO Meeting, Fall 2012
Following are some key points from the meetings in Chicago.
The RESO organization: RESO has $475k in 2012 income – plenty to get the standards process moving, staffing it appropriately and funding special projects, for example to create and support a tool to provide certification with standards compliance. The RESO board will charter workgroups to address industry needs using a new process – including a work plan, and having drafts posted to web for comment – with member notification. There is a Technical Committee and Workgroup Policy and Procedures Manual that clarifies this process. Soon the technology committee, with significant work being done by CRT, will be integrating work group projects, posting milestones for work groups on the website so that progress can be better tracked, post notes from work group meetings, and unify the groups into one technology platform to make the whole standards process easier to manage. The website is currently out of date in many areas, and the technology committee will soon develop a regular website review and clean it up, communicating workgroup progress to the community on a monthly basis.
Legal update: When RESO members submit materials to RESO for inclusion in the standard, they are ceding intellectual property rights. Members mustdisclose possible infringements. Before specifications are published, members will get a notice to disclose their patents. A member can license a patent to RESO or exclude it. Failure to respond would be the equivalent of granting a license for their intellectual property to RESO. RESO will also be cracking down in the next year on logo misuse. RESO has produced a variety of logos, and each is only to be used for specific purposes where a license has been granted.
Adoption and Certification: Based on NAR rules, NAR-affiliated MLSs must implement major new versions of RETS 12 months after there’s a tool available to test for it. That’s why creating a new certification tool is an important project! Certification provides transparency as to who is RETS compliant. RESO will certify “client” systems, “servers”, and now … “sites”. Sites are the local MLSs and other RETS server implementations, and certification is needed because while a server platform provided by a vendor might be certified, a local implementation, once customized to local needs, may not be compliant. RESO will publish detailed reports, including performance of optional tests (i.e. the “Update” transaction). RESO will charge certification fees to recover costs of the compliance effort. There will be discounts for RESO members and for re-certification. The cost of certification has yet to be determined. There was a long discussion of whether to publish when a RETS provider failed a certification test. It was tentatively decided that RESO members could test their RETS applications under development in private, then decide when they were ready for the certification test to be made public. To be certified, all “musts” from the RETS specification would need to be successfully tested – though someone may want a non-certification test result published, if they were fielding a limited application that didn’t do all of the “musts” but successfully achieved passed compliance testing for a more limited part of the specification. One great suggestion made during the meeting was to have the certification tool benchmark RETS client and server speed.
Following are summaries of the technical workgroup activities:
RETS Data Dictionary: This has been a highly productive group, and the first version of the new “data dictionary” – the holy grail of our data standards efforts these many long years – has already been posted on rets.org. At the RESO meeting, we reviewed some minor dictionary changes, and also looked at the starting point for the next part of the data dictionary, relating to contacts. Then we discussed which types of data would be focused on next – in priority order: open house / tours, listing transaction history, media, saved searches, prospecting, commercial, tax, business rules. This group will be touching base soon with the providers of proprietary APIs to see if there is work they have done that could be used as the starting point for data dictionary standards for these additional data types. Rob Larson leads this work group.
RETS “Transport”: The new RETS transport will embrace modern widely adopted programming paradigms. The group is already agreed on a basic structure for moving RETS data in a more modern API-like way. The plan is to use oData for the query language – similar to what proprietary API publishers had chosen. Standard names will be used as query parameters. No decisions have been made on new security and authentication methods yet. The workgroup plans to reconcile all the existing proprietary APIs and may choose use cases and syntax from a specific API – creating a superset. This process assumes that those proprietary API providers allow what they have created to freely be used as part of the RETS standard. Almost all of the API providers I have talked with so far have said they would be open to this – they don’t want to be the ones left out in the cold with their proprietary API – better that it become part of the new RETS standard! According to the Transport work group leader, they will start publishing API drafts in next 30 days and publish more info on security in 45-60 days. Subgroups may be started. Within a few months, the Transport work group plans to publish reconciled APIs, have discussions and take initial comments, and have recommendation ready in a few months for comments and ratification, likely this coming spring. Scott Petronis of Onboard Informatics leads this workgroup.
RETS Syndication: – The Syndication work group is charged with coming up with a “light weight” way to move data in ways needed for websites that need basic data for display. Over 120 sites currently use the RETS work product this group has created. There has been some divergence with the “data dictionary” work, and this group will work to bring the two products back into line. Of future interest to this work group are areas such as rental fields, commercial sub types, and a global address taxonomy. This effort will coordinate with data dictionary work group. Paul Stusiak of Falcon Technologies is the chair of this group and James Martin from Listhub is vice-chair.
Research and Development: This workgroup has been evaluating priorities with relation to the Data Dictionary, Transport, and new payloads such as Open House, Saved Search, Contacts, Events, and Standardized Address. This has been reflected, as noted above, in other work groups’ efforts. This work group also suggested that enhancements be evaluated relating to mobile application data access – creating simpler, more lightweight methods of accessing the data perhaps using JSON, RETS, and oData. This work group meets every 2 weeks, Thursday at 2pm ET. One can Google “RESO Research and Development” for associated documents. David Harris and Rob Overman lead this work group.
The RETS efforts are clearly accelerating. I hope that anyone not already contributing to the effort will consider doing so, and that organizations that have not yet stepped up to fund and become a member of RESO will do so as well. More information is available at http://www.rets.org/
Share this post: