[Rets-dev] Re: Search responses and StandardNames

[Peter Williams]

Today's Topics:

   1. Re: Search responses and StandardNames (Paul Stusiak)
   2. Re: Search responses and StandardNames (Paul Stusiak)
   3. RE: Search responses and StandardNames (Sergio Del Rio)
   4. Re: Search responses and StandardNames (Marc G. Smith)
   5. Re: Search responses and StandardNames (Paul Stusiak)
   6. Feedback requested - RETS 1.7 COMPACT format <COLUMNS>
      interpretation (Paul Stusiak)
   7. Re: Search responses and StandardNames (Paul Stusiak)
   8. Re: Search responses and StandardNames (Marc G. Smith)
   9. RE: Feedback requested - RETS 1.7 COMPACT format
      <COLUMNS>interpretation (Sergio Del Rio)
  10. RE: Search responses and StandardNames (Sergio Del Rio)
  11. Re: Search responses and StandardNames (Paul Stusiak)
  12. Re: Search responses and StandardNames (Scott Gifford)
  13. Re: Search responses and StandardNames (Scott Gifford)
  14. Re: Search responses and StandardNames (Scott Gifford)
  15. Re: Search responses and StandardNames (Scott Gifford)
  16. Re: Search responses and StandardNames (Paul Stusiak)
  17. Potential minor ambiguities in the RETS2 Service Document
      (Paul Stusiak)


----------------------------------------------------------------------

Speaking only as a standards architect listening to the argument, and also thinking about what the evolving RETS2 market is all about:-

RETS 1 seems to support a traditional realty interworking practice, that is still prevalent in many parts of the country. This is one in which an automated backend system (e.,g. broker) might send off a request to a processing queue, using standards names and noting a client UA name. It can expect to get a result (from an MLS) whose format SHOULD target that particular client UA, given said installed UAs in broker field offices have certain set of fixed field display capabilities. Standard names on queries do enable a "bigger broker: working with *multiple* MLSs to formulate 1 standard name query, queue the single request at the several MLSs, and obtain results from each that are already fully and uniformly tuned for the single (preset) presentation capabilities of the broker's interactive systems actually used by agents sitting at office PCs/terminals.
 
A typical, internet-era client could intend to issue a request with standard names intending that the result come back in XML using standard names, assuming that several stages of dynamic reformatting (via XPATH and XSL type reformatters) will occur client-side during post-processing. In this latter case,  the XML would naturally come back with standard field names. That's presumably why one wants the XML - a generic data-set that is presentation-independent - to support client/server design patterns in n-tier systems. Offering the XML format seemed to be allowing for a (then-future) RETS product space that went beyond merely standardizing interworking with the 80s/90s generation of brokerage systems with fixed listing forms and fixed data-loading practices for those forms.
 
I CAN see why, when writing a standard for adoption by many **many** legacy brokerage systems (with fixed listing presentation systems) that are attempting to cooperate with several MLS (with different request query interfaces ) , that (a) it is necessary to separate field names used in queries, from the field names used in the formatted response, and (b) a request may be optionally presented in standard name format ...or not ...where standard names in request exist mainly to enable a (Single) requestor (broker) hub to "enforce request-standardization" upon its (Multiple) responders (MLS) spokes.
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 5351 bytes
Desc: not available
Url : http://lists.rets.org/pipermail/rets-dev/attachments/20070221/4d517221/attachment.bin