[Rets-dev] On the Status of RETS2 and the reasoning behind multiple documents to define the standard

[Paul Stusiak]

The thread Google Base Housing vs. RETS has spanned many different 
topics, making a single response very difficult. Instead, I will attempt 
to reply to some individual comments. Please be aware that the context 
has been narrowed and that may result in the loss of the overarching 
context. The intent is not to pick on specific people who participated 
in the thread, but to correct what I see as some misconceptions.

fwanicka wrote

<quote>
Ummm, I think there are a lot of people on the list that would disagree 
with that, assuming we are talking about 1.x, since 2.0 is not 
finalized. In a vacuum, your statement might be true. But it’s failure 
to build upon virtually any existing standards means every piece of it 
needed to be learned from scratch. Most standards attempt to build on 
other standards, which means the true level of complication is less. And 
2.0 looks to be pretty complicated as well. I’m already seeing 
discussions of RETS Lite on the list before 2.0 is finalized. That 
should tell you something.
</quote>

The first portion, RETS2 Service, is finalized. People are already 
coding against it. RETS2 was separated into several different portions 
to simplify change and to reduce the bulk of the documentation - 
different documents reflect different uses.

RETS1 only had a single standard document with a weakly defined 
mechanism for changing the ancillary documents, the DTD, data 
dictionary. Some may argue that the whole mechanism for change was weak 
in RETS1. The single document defined two major areas and a couple of 
minor ones. The major areas were the metadata and the transport + 
transactions. Security was very briefly discussed. Standardized data was 
not formally discussed in the standard except to mention that where 
there was a match between a standard name and the underlying data of the 
implementation that there should be a standard name available. Of 
course, this is all roughly speaking.

So, for RETS1, we had several things that caused problems with 
interoperability. Compliance was set low to start. Security was not well 
defined and did not provide sufficient control to work in some of the 
business scenarios that were described. Data standardization did not 
receive sufficient support from the standard and in practice was not 
usable. There was too many optional sections that resulted in some 
conflicting states. The broad developer community, with some exceptions, 
was not sophisticated enough to take advantage of the metadata exposed 
by RETS1.

To attempt to address some of these problems, the RETS2 effort was 
divided into different parts. The RETS2 Service portion is roughly 
analogous to the RETS1 document. RETS2 is built, as much as possible, on 
preexisting standards. Many of these standards are quite complex. To 
offset the complexity of the referenced standard, we get the benefit 
that there is tool support from within most of the major development 
platforms.

Paul
Falcon Technologies Corp.