[Rets-dev] On Variations on Specification Implementations and Balancing required versus optional

[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.


jp.fielding wrote

<quote>
i think hes saying that gbase has a smaller barrier to entry than rets 
from a client perspective.   as a rets client user, i have to agree.  i 
currently maintain the retsclient java api originally started by cart.  
it works great, but keeping it working transparently across each vendors 
interpretation of the RETS spec is sometimes tricky.   not only that, 
some things we have to do cant go into the spec.  for instance, one 
vendor, has search limits, but doesnt provide for paging. [snip]
</quote>

Comparing googlebase to RETS is an apples to oranges comparison as 
others have pointed out. Your observation that getting the standard to 
work transparently across vendors is true. There are some challenges. I 
would point out that the situation previous to this was much worse. 
Vendors previously may have not provided any technique for exposing data 
or may have used some untimely and frequently broken ftp method. Today, 
in general, if you can resolve the vendor's different interpretations of 
RETS, all the same vendor systems will function the same. At the very 
least we have changed the problem from "how do I connect to 800 /1300 
different systems?" to "how do I connect to the 20 or so different 
system and adapt to their different data fields and do I need to care 
about the remaining non-RETS systems/" which I would categorize as some 
progress. As well, we have been able to move some/many from a stale 
data, once per day if we're lucky and the ftp didn't break to an on-line 
up to date view of the market. For some applications this is not 
important. For others, it would be impossible to provide a product that 
did not have the direct, live access to the system.

I would point out that variations in the implementation of 
specifications is not exclusively a RETS problem. One of the very first 
problems of interoperability that occurred with RETS1 was that the 
internet standard RFC 2617, adopted June, 1999 was implemented slightly 
differently by that other collection of phds, Microsoft, where an 
optional field was made mandatory. Given that almost everyone used 
third-party libraries for this function, the interoperability problem 
was wide-spread and had nothing to do with RETS other than it referenced 
the "standard" RFC 2617.

I would also remind everyone of the ongoing issues between mail servers 
and the work-around techniques used to resolve differences in SMTP, POP 
and IMAP, all of which are well-known, old standards. This is common 
within any standards community.

Since this seems to be the nature of the beast - more flexibility leads 
to less interoperability, we can clearly see the balance that must be 
struck. Constrain the standard to improve the interoperability at the 
cost of removing potential valuable flexibility to meet business needs. 
While any balance struck must be imperfect, hopefully we have got within 
an acceptable range with RETS2. Where possible, RETS2 attempts to choose 
greater constraint over greater flexibility, recognizing this short 
comings of the RETS1 document and compliance process.

-- 
Paul
Falcon Technologies Corp.