[Rets-dev] RETS 2 Service Document posted to www.ftc2.com

[Jeff Brush]

At the risk of 'twisting' and defeating 'original' purposes let me explain 
some of the rational behind R0043- the requirement that vocabularies must be 
searchable.

The expectation for RETS2 is that most requests will be for XML documents. 
This was true to the extent that the RETS community even voted to exclude 
COMPACT from RETS2.

In the context of XML, the only field names that are relavent are thoses 
used in the query clause. Does it make sense to at least quadruple (or even 
10x) the size of all vocabulary document to support non-searchable fields 
that will not be referenced.

In the case of DELIMITED payloads, DELIMITED data was added back into the 
spec at the request of client-side users. The primary purpose was to allow 
data replication. Because MLSs historically have a difficult time mapping 
names other than system names to their data, we didn't feel the need at this 
time to implement other vocabularies that have yet to be defined. (We hope 
to identify a more optimal replication method in the future.)

A little perspective is sometimes helpful.

Jeff Brush
Chief Architect
Ronin Technologies



>From: Steve Clarke [mailto:Steve.clarke at firstamericanmls.com]
>Sent: May 18, 2006 6:28 AM
>To: Sergio Del Rio; Paul Stusiak; rets-dev at rets.org
>Subject: RE: [Rets-dev] RETS 2 Service Document posted to www.ftc2.com
>
>Yea.  I thought we called that a "vocabulary" too.  But in the current
>draft spec, that meaning (of vocabulary) has been twisted by R0043 which
>now attaches an inherent functional limitation (must be searchable) on
>the vocabulary fields.  That change now implies that we are
>substantially missing something from the metadata and it also creates a
>redundancy with the IsSearchable attribute in the dictionary.  In my
>mind, the fact that we even have an IsSearchable attribute in the
>dictionary validates the original intent of a vocabulary to be exactly
>what you are asking about.  Certainly that's what I thought too.  But
>R0043 kinda defeats the original purpose.
>
>Smc
>
>-----Original Message-----
>From: rets-dev-bounces at rets.org [mailto:rets-dev-bounces at rets.org] On
>Behalf Of Sergio Del Rio
>Sent: Wednesday, May 17, 2006 11:31 PM
>To: 'Paul Stusiak'; rets-dev at rets.org
>Subject: RE: [Rets-dev] RETS 2 Service Document posted to www.ftc2.com
>
>OK, I must be tired.  I thought it was there at some point, but now I
>can't
>see it.  What happened to the metadata tag concept that was going to
>reduce
>the amount of different metadata that we were going to have.  Did we
>replace
>this simply with different Vocabulary or Data Dictionary versions?
>
>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 Paul Stusiak
>Sent: May 16, 2006 3:02 PM
>To: rets-dev at rets.org
>Subject: [Rets-dev] RETS 2 Service Document posted to www.ftc2.com
>
>Changes for FC5
>
>1. Remove section 2.4
>
>2. Add requirement
>
>R0148	A Provider SHOULD return a fault when an invalid Field Name is
>used
>in a
>Query by the Requestor.
>
>and modify the text preceeding to clarify the behavior of Vocabulary
>under
>security and system reductions.
>
>3. Correct select statement for the Delimted ObjectType to use either
>the
>WellKnown Vocabulary field names or the DataDictionary field names.
>
>4. Update R0138 from presented to present
>
>5. Update R0139, adding the preamble "If DisplayGroups are present in
>the
>Vocabulary document," to the beginning of the document.
>
>6. Added a reference section pointing to the RQL Query Language
>documents.
>They
>are currently only available on the mirror site and not on rets.org.
>
>The document will be bookmarked and an index added after the final vote.
>
>It is now posted to www.ftc2.com
>-----------
>Paul Stusiak,
>President,
>Falcon Technologies Corp.
>_______________________________________________
>Rets-dev mailing list
>Rets-dev at rets.org
>http://lists.rets.org/mailman/listinfo/rets-dev
>
>
>
>_______________________________________________
>Rets-dev mailing list
>Rets-dev at rets.org
>http://lists.rets.org/mailman/listinfo/rets-dev
>
>
>_______________________________________________
>Rets-dev mailing list
>Rets-dev at rets.org
>http://lists.rets.org/mailman/listinfo/rets-dev