FAQ

RETS as a standard body is absolutely FREE. You will incur costs for developing solutions implementing RETS.

When someone brings a new toaster home from the store, he or she never worries whether the plug will fit in the kitchen outlet or if the house has the right kind of electricity. That person is relying on a set of standards adopted by the appliance manufacturers and power companies to assure that things work together.

In the software industry, standards perform a similar function. They are not programs themselves and they do not get installed on any computer. Rather, standards are sets of rules that independent developers can follow to create software that will work together with other software built using the same rules. But they do not define what the program should do, just as the electrical standards do not specify whether a new appliance should make toast or brew coffee.

There are two ways standards can come into existence. Many companies in an industry may be solving a particular problem in a certain way. Perhaps they are copying a market leader or going along with a tradition. That solution has become a de facto standard, whether or not it's been officially sanctioned. The other option is for an organization or consortium to create a solution to a particular problem and to publish it as a standard for others to use. It only becomes a true standard, however, when enough other people actually start using it.

RETS has been developed taking the second route.

The Real Estate Transaction Specification is a document that defines a series of computer interactions called "transactions" and serves as the definitive reference source for developers who implement them. It establishes the parameters for each specified transaction, both upload and download, as well as the expected behaviors and results that compliant hosts and clients must be able to manage, including error codes.

The RETS2 Payload XSDs and the RETS 1.7 and 1.5 Real Estate Transaction DTD relates to XML (for eXtensible Mark-up Language), a technology that many observers believe has the flexibility and power to transform electronic commerce. The key capability of XML is to make data self-describing - that is, it sends "tags" with the data to tell the receiving computer what the information is, how it relates to other information and what to do with it.

For instance, a search result may report a value of "3" for one feature of a house. To know whether that means three bathrooms or three bedrooms or three acres in a traditional MLS system, the receiving computer must be told about the database structure on that particular host. In XML, the specific host is immaterial. By reading the attached XML tags, the receiving computer could recognize that "3" means the house has three bedrooms, a bedroom is a type of room, and the number of bedrooms can be included in the total number of rooms.

In addition, XML allows a data hierarchy, so that values from several fields can be combined under one label. As an example, the label "street address" could be defined as including the information for house number, street directional prefix, street name, and street direction suffix.

XSD is an acronym for XML Schema Definition used to formally describe the elements in an Extensible Markup Language Document. RETS2 uses XSD because it has the following advantages over DTDs: it is more direct, written entirely in XML (no need for intermediary parsers), includes self-documentation, and has the ability to be queried through XML Transformations (XSLT).

DTD is an acronym for Document Type Definition, a document that describes the tags and hierarchy structure for a particular set of XML data such as RETML, the RETS DTD that relates to real property listings.

RETS 1.x RETML incorporates approximately 140 commonly used fields that are found in some variation on most MLS systems, providing a substantial subset of the property information that will be highly useful for a number of typical applications.

However, RETML does not attempt to be comprehensive or to provide a basis for a stand-alone XML-based MLS system, nor does it support the update transaction that is part of RETS. In fact, a RETS 1.x compliant system need not even maintain all of the fields in RETML, although in response to a query it must pass meaningful data to inform the client that the requested field is absent.

RETS2 Payloads are designed to be more comprehensive and support the functionality of the Real Estate Transaction Lifecycle. MLS Payloads, which have inherited many of the standard names from RETML, are smaller and targeted at certain functions or resources. RETS2 XSDs also include Transaction Management System (TMS) Payloads and NRDS Payloads.

RETS2 is designed to accommodate the continued development of XML in two ways. Payloads are intended to be a minimum common set of fields. They can be locally extended to add information of particular importance in a given market area. Although a client is not required to interpret those extensions to be compliant, competitive pressures will move software companies to include that feature in their products if it proves to have market value. Also, RETS2 allows providers to develop and publish their own Schema, DTD or other custom payload.

Even more fundamentally, the RETS Transactions (Search, Update, etc.) do not depend technically or functionally on either the RETS2 Payloads or the RETS 1.x RETML. This means that the payloads and the transaction sets will be able to develop at their respective speeds along parallel paths without disrupting the integrity of either.

The XML format will be most useful to client software that prefers to deal with the standardized subset of fields described by a XML Schema or DTD. For the benefit of being more generic, that type of application will be willing to forego some of the information available on a host and to accept what it does receive in a different format than the host employs (for example, in plain English expressions instead of coded values). Sample applications that might benefit from XML data transfer would include CMA and flyer generation programs that produce consistent documents from different host systems.

A well-defined, well-accepted standard has the potential to benefit different industry groups in different ways.

Agents: A standard will make it easier for software vendors to enter the real estate arena and to sell their wares into a national market. That should result in more choices for agents and more powerful tools that are better integrated with the MLS data. It should also increase competition in local market areas.

Brokers: Broker office systems will be able to exchange information much more easily with local MLS hosts, both upload and download. This will be particularly beneficial for companies that need to manage listings in more than one MLS. RETS can also encourage the creation of enterprise-wide solutions that link functions such as inventory control, transaction management and agent productivity. Under the standard, tasks like populating web sites, generating print advertisements and organizing transaction services will be easier and more accurate.

MLSs: Having the standard will improve the price/performance ratio for property information systems. Software developed using RETS will give MLS operators more options to offer the membership, such as a wider variety of access software, data export services, Internet/web services and other value-added service integration options. It will open up possible new business opportunities, such as functioning as a service bureau to provide fee-based technical capabilities to local brokerage firms.

Client software programs will enjoy more reliable and consistent connections with the MLS server, reducing support for applications that 'break' when MLS changes are implemented. Additionally, clients can be written to work across different MLS systems, allowing agents to retain their familiar software when MLS vendors change and reducing training costs.

NAR: NAR benefits when its members are served. By facilitating the development process and sponsoring adoption of RETS, NAR is promoting the technology environment that will prepare REALTORS® to become managers of the electronic transaction.

Vendors: RETS will allow software vendors to use a single interface across many compliant systems rather than creating and maintaining multiple custom interfaces. That will save development time and resources that can be applied to lower costs or improve features. In addition, development and distribution of software to a large variety of MLS systems in different geographic locations can be dramatically easier, encouraging new products by opening larger market opportunities.

Industry: RETS will assist the real estate business climate in several ways. Introducing Internet-based technology such as XML will allow more profitable integration of the Internet into business. Creating a common communications protocol will establish a framework for the electronic real estate transaction and supply a core technology around which industry sectors can collaborate. The standards change process will introduce an accepted process for technological initiatives in the industry. Most significantly, the entire standards effort will provide a platform for improved service offerings to consumers.

Brokers, Agents and MLSs have been seeing the benefits of using RETS for the past several years. For details on how RETS benefits users, and some innovative RETS success stories, you can refer to the Comprehensive Overview document on this site.

In saying that a piece of software fully complies with RETS, the vendor is claiming that the programming code properly follows all of the rules laid out in the standard, that the product performs all of the functions mandated by the standard, and that the program will successfully execute the RETS transaction sets when used in conjunction with another piece of software that also complies with the standard.

Two fully compliant products, however, will not necessarily be equal. Programs will still compete on issues such as their range of features, the quality of their screen designs and the intuitiveness of their operations.

Besides comparing a products functionality against the requirements set forth in the RETS2, RETS 1.7 and 1.5 Specification documents, you can determine a product's compliance by either looking for it on the list of compliant servers or clients, or test your own product against one of the compliance checkers (Server or Client). Please refer to the compliance section of this site for more information on RETS compliance.

This question actually presents two distinct issues: (1) whether the existing MLS computers can accommodate the additional data and the Internet-based communications protocols required by RETS, and (2) whether the format of the information maintained on the system is compatible with the specified data exchange procedures.

It's easier to answer the second question first. The design of RETS contemplates a type of information layout that is used by virtually all of the current MLS systems. That does not mean there is necessarily an exact correlation between the current listing form and the RETML, the RETS data dictionary (or XML DTD) employed for some types of data exchanges. However, it does mean that the existing MLS information almost certainly can be described in a way that matches the requirements for basic data exchange.

For two reasons, there is less assurance that an existing MLS system can handle the communication requirements. First, some servers lack the available storage space for the additional descriptive information that RETS requires a host to provide. Second, not all servers can support the Internet-based communications protocol on which RETS is based.

Even if a particular MLS system does not meet the requirements for RETS, however, that does not mean it must be replaced. Another option may be to install a RETS -compliant parallel system that draws the information from the main host and then stores and provides it in accordance with the standard. That solution may be available from the same vendor who supplied the present system or from a third-party provider.

That would be highly unlikely. As noted in the previous answer, RETS is consistent with the way most if not all listing forms are currently designed.

In response to comments received on the initial draft, an update transaction has been added to allow modification of data on the server. The content may be new or changed listings, agent records, office information, new photographs or any other file modifications. RETS will allow data entry to be done online or offline, depending on the client software being used.

When data is being entered, most if not all traditional MLS servers have a way to check for errors, for example, to make certain a new listing includes all the required fields. These "business rules" can become highly complex because of issues such as field interdependencies (e.g., the list of valid school districts depends on what county is entered) and conditional relationships (e.g., "selling agent" must be entered if status is "sold" but not if status is "active"). If the attempted modification violates any of the business rules, the host rejects the change.

RETS provides a way for the host to communicate all its business rules to the client. The client can then be designed to mimic the host's validation operations with a high degree of reliability, so that data can be entered with great confidence that it will be accepted when sent to the host. This is a major benefit if an office enters a number of new or changed listings offline during the day and later uploads them to the MLS server in an automated operation overnight.

No. Simply installing RETS will not require anyone to change the way they use real estate information or communicate with the MLS system. One of the specific design objectives for the standard was that it would add new functions without disrupting the current ways of doing business. Obviously, some practitioners may choose to make technology investments that will let them take advantage of the new capabilities to become more competitive.

Nothing in RETS dictates that standards-compliant programs must run on any particular type of computer or operating system. The Macintosh has tools that support both HTTP and XML, making applications that use this standard easier to develop. Whether software companies produce versions of their products for the Macintosh platform will depend on market demand.

Where that can be done without introducing significant complications, the standard accommodates international activities as, for instance, in the transmission of date and time information. However, no specific support was added for languages other than English, and no specific international fields were added. If market demand warrants, those will be appropriate topics for the change process.

The exact cost for particular installations will be specific to each individual MLS and its technology provider. It will depend on many variables such as the age, configuration and capabilities of the present host computer; the current telecommunications infrastructure; the size and design of the listing database; the complexity and uniqueness of the governing business rules; and the contractual relationship between the parties.

NAR has secured commitments from major MLS vendors that they will begin to incorporate the standards into future releases of their software. While NAR does not expect software companies to implement the standard at a loss, neither does it expect vendors to make windfall profits on the implementation.

ABSOLUTELY NOT! All access to an MLS system will still be password-protected and subject to all of the security settings and business rules in place today. Because the log-in process identifies the application being used as well as the individual using it, an MLS will be able to allow some compliant client products to access the server while refusing others for whatever technical or business reasons it deems appropriate. There is NOTHING in the standard that either recommends or obligates a host system to circumvent any current security settings or business rules.

There are a number of key differences between the currently proposed standards and DxM. Most significantly, RETS is built on readily available, well-defined and well-accepted Internet standards, affording a high degree of confidence in its fundamental soundness and making implementation much simpler. DxM was developed before these technologies were available and required additional software tools to operate.

Secondly, RETS separates the communications and data exchange components of the standard from the data content covered by the XML DTD. The DTD itself covers only the most common fields that account for the overwhelming majority of data requests. DxM, by contrast, focused on the data elements themselves and attempted to provide a comprehensive dictionary of real estate information, resulting in an unwieldy data set with some 2,500 data elements that combined into over 50,000 data items.

Finally, RETS is truly an open standard using well-known technology and committed to industry guidance through a public process. DxM was created using proprietary technology, an approach that runs contrary to the fundamental objectives of a standard.

The only people who really need to delve into the details of RETS are folks like developers, consultants and computer professionals whose jobs involve technical analysis. MLS executives and brokers probably need to know enough to talk intelligently to their technology partners and to ask for assistance in understanding how the standard can benefit their own operations. Agents should at least be aware that this initiative is underway as part of the larger shift in real estate practice and those who are so inclined may want to consider its implications for how they manage their personal business technology.

To determine the best way to proceed with RETS, local real estate leadership needs to consider their current technology level as well as ways the standard could help them reach both technical and business goals. For MLS or association executives, that means opening a dialogue with technology partners such as computer staff, consultants, advisors and vendors. Make sure they have copies of the full detailed standard and ask them to evaluate the potential of RETS as a strategic tool. Many of the more technology advanced brokerage firms will have valuable insights as to what the standards can accomplish.

In many areas, the MLS system is the most likely starting point for the standard. Local leadership should ask the MLS vendor to provide a position statement on RETS and a projected implementation schedule. Even if a price quote would be premature, request a scope analysis to look at some of the factors that will bear on the eventual cost. If it appears the current system might not be a good candidate to implement RETS, talk to the vendor about whether an alternative solution such as a parallel system would be feasible.

Along with the technical and cost considerations, defining a business purpose for the standard is a vital step. RETS is enabling technology that will provide the greatest value to those who understand how they want to use it. This is an opportune time to open or expand discussions within an organization or company about the types of benefits that RETS could bring to that particular entity, to the local real estate community and to the industry at large.

Gathering information on the probable timing and technical scope of implementation, the likely cost and the potential benefits will identify critical factors for a decision. Even at that point, it will often come down to a choice between calculated risks of going ahead without assurances or of lagging back and being left behind. The future of RETS may well depend on whether industry consensus resolves those doubts in its favor.

In February 1999, after a number of meetings with a variety of constituencies, NAR brought together an industry task force to begin the standards development effort. The group included representatives of MLS vendors, client application vendors, MLS operators and industry consultants. Collectively, the members reflected extensive real-world experience in design, development and implementation of real estate information systems and a strong working knowledge of business needs of REALTORS®.

After the task force concluded their initial draft work, NAR convened a group of industry leaders in the spring 1999. This so-called Group of 50 included REALTORS®, REALTOR® board members, real estate franchise staff, MLS operators and staff, MLS and client software vendors, industry consultants, and other industry participants. The task force presented their efforts to the group, answered questions and listened to suggested modifications.

The draft standard was then presented at the NAR Mid-Year meetings in Washington, D.C. and posted on the Internet for a public comment period. The task force revised the standard based on the comments received and reviewed the new draft with the Group of 50 at another meeting. Additional refinements from that session were incorporated into what was Version 1.0.

Point your Internet browser to http://www.rets.org/documentation.