[Rets-dev] RETS Future Direction

[Sergio Del Rio]

Well this is quite radical...

Having two specifications to support is just asking for trouble I think.

Can you please explain why you think that the Compact format in RETS 2.0
will be so much bigger than that in RETS 1.X?  Personally, I don't think it
will be any larger than it is today, with perhaps, the exception of a few
bytes.

Regards,
Sergio Del Rio
Templates 4 Business Inc.


-----Original Message-----
From: rets-dev-bounces at rets.org [mailto:rets-dev-bounces at rets.org] On Behalf
Of Stuart Schuessler
Sent: May 1, 2007 10:16 AM
To: Rets-dev at rets.org
Subject: [Rets-dev] RETS Future Direction

I just wonder if the XML payload in RETS 2.0 is not going to be a problem.
While a transaction management systems will mostly be dealing with a single
listing record, the primary use of RETS is downloading large data sets and
doing some sort of analyses on that data.  Having an XML wrapper around
large data sets does not really make sense.  The bandwidth is an issue but
do not forget the amount of time to download the data.  It was already a
problem in RETS 1.x XML without the additional schema information.  This may
be a fundamental flaw with the architecture in RETS 2.0.  We may have a
situation were the RETS 2.0 standard cannot be implemented for downloading
data, but rather it is more of a transaction standard like ACORD and MISMO.

Even looking at the compact data response we are still looking at a large
download in RETS 2.0 not to mention the additional arguments the server
vendors must go through in explaining that they cannot deliver large data
sets in XML.  This is actually a big problem.  Does the standard support NOT
allowing XML download?  Can it be turned off?  Can the server allow certain
clients to receive XML and others receive COMPACT or is it up to the client
making the request.  Where are the data controls for the server vendor?

I could see where an MLS Server Vendor would provide a RETS 2.0 interface
for Transaction Management Systems and provide a RETS 1.x interface for
everyone else.  We then have two standards that are generated and the RETS
1.x standard goes forward which seemed to be the consensus of the room at
the last RETS meeting.

The fundamental flaw of the architecture may be that it was NOT written to
support the current business practice but rather a futuristic practice of
transaction management.  The question that has to be asked is:  Is this the
fastest way to download large data sets?

If RETS 2.0 main goal is to have a SOAP interface then adding one to RETS
1.x would not be that difficult and we would still preserve the support for
the current business practices along with preserving a standard that has
been agreed upon since 1999.

I would recommend going forward with splitting the standard into an MLS Data
Standard (RETS 1.x) and a Transaction Management Standard (RETS 2.x) with a
common set of standard names.  This would actually free up RETS 2.x to
pursue a more focused transaction management standard.  We could then put a
SOAP interface on RETS 1.x to make it easier to implement and we have
preserved 8 years of standards work.

I do not think that it does transaction management or MLS System any good to
combine the two into one standard because of the compromises that need to be
made.  You end up with neither one being supported very well.

Stuart

_______________________________________________
Rets-dev mailing list
Rets-dev at rets.org
http://lists.rets.org/mailman/listinfo/rets-dev