[Rets-dev] Contemplations on RETS 2.0

[Matt Lavallee]

Hi everyone,
 
Being out at Inman discussing the new standard with colleages and processing
the myriad changes that have gone into the standard over the past five
months, I have some concerns over complexities in the standard that may
introduce "disparity loopholes" among systems.  I'm going to list some of
these below and hope that the community and stakeholders can explain why
certain parts of the new standard are the way they are...
 
1. Exclusivity between the "Resource" model and the standards-defined
"Payload" (i.e., output) model.  Is there any particular reason that these
exist independently, and is it reasonable for us to consider merging the
two.
 
2. As anyone who has attended the Payload meetings knows, I am not a big fan
of the Vocabulary or DataDictionary structures.  In fact, as time has
progressed, I've deepened my position to feeling that these are bottleneck,
meta-meta loopholes that will only serve to harm implementation of the
standard (as a true, universal standard).  Given that each of these is
extensible and overrideable, it's conceivable that any "compliant" system
could be entirely foreign when compared to any other compliant system
because of liberal [ab]use of the meta-extensibility model.  If #1 (above)
can be satisfied, is there continued need for these two structures outside
of custom payloads/resources?  To that end, is it necessary that they be
related to the existing (standards-defined) payloads at all?
 
3. Extensibility and replaceability of the standard payloads:  They have
been used in defense of the uber-standard model quite a bit, given that if a
certain payload does not meet the needs of the local system it is open to
ad-hoc extension.  While this flexibility is well-intended, it does give
rise to the likelihood of remarkably dissimilar systems (to this I point to
REIL and the use of additional RETS 1.x Resources to define common things
like cities).  I would propose that, in order to be compliant, every system
MUST support the standard payloads (as defined by the standard, with the
standard's data types), and MAY provide alternative payloads that include
local redefinition.  To this end, all of the fields in the standard schema
would need to be closed to disallow extension.
 
I realize the points above may be a radical shift to rigidity, and I have no
intent of devaluing the work that went into making the standard broadly
applicable.  However, the limited pain imposed by forcing some data homogeny
for the sake of a reliable transport would be greatly outweighed by the pain
felt by the masses (for years to come) as the standard is consumed.  I
earnestly hope to avoid the death-by-a-thousand-papercuts that has plagued
RETS 1 adoption.
 
-Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rets.org/pipermail/rets-dev/attachments/20070801/321ea76f/attachment.html