[Rets-dev] Contemplations on RETS 2.0

[Michael Wurzer]

This conversation has occurred before and I learned then that discussing 
the concepts of data standardization in the abstract is unlikely to be 
fruitful.  Both sides to the discussion have good points, in the abstract 
(basically, the positions boil down to those focused and usually remain 
unpersuaded of the others' position.

However, the payloads workgroup has shown that discussing the concrete 
detail can result in broad agreement.  The big question, though, is how we 
extend the good work done so far on member, team, etc., on to the breadth 
and depth of the listing data, which we haven't delved into too far yet.  I 
think what's there is quite good, but we need broader participation and 
input to get the kind of agreement that will allow for stricter 
requirements for compliance.

As we discussed at the last payloads meeting, we need to define a process 
for how the broad variety of constituents can provide input and then we 
need someone to harmonize the input.  As this work is being done, we'll 
have much more opportunity to discuss the strictness of the standard within 
the context of specific fields.

All that being said, I also don't think it is productive to delve back into 
the data types discussion right now.  We'll have a big enough hurdle 
discussing the fields without also requiring strict data typing.  

To summarize: stick to specifics, establish a process, and set aside data 
strict typing for the moment.

Michael
--------------------------
Michael Wurzer
President and CEO
FBS Data Systems
mwurzer at fbsdata.com
www.flexmls.com/blog
800.437.4232 (office)
701.306.9341 (mobile)

...... Original Message .......
On Wed, 1 Aug 2007 18:38:52 -0500 "Matt Lavallee" <matt at mattL.com> wrote:
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
_______________________________________________
Rets-dev mailing list
Rets-dev at rets.org
http://lists.rets.org/mailman/listinfo/rets-dev