[Rets-dev] RETS2 MLS Payloads for Vote on December 7th

Thu Nov 30 13:40:04 CST 2006

Hi all,

Although it seems reasonable to add such items as Photo Date and Number
to the Listing schema, it falls short of future development using other
media forms such as doc, rtf, pdf, etc... However if media information
is managed separately from the Listing records you can update the
desired media using the content in the media schema. This also allows
you to organize media for other records such as Members, Offices,
Contacts, or any other record type you need to expose. There are trade
offs for both approaches, so it probably needs further research and
discussion.

Thanks,

Matthew P. McGuire
First American MLS Solutions

-----Original Message-----
From: rets-dev-bounces at rets.org [mailto:rets-dev-bounces at rets.org] On
Behalf Of Dan Woolley
Sent: Thursday, November 30, 2006 2:26 PM
To: Jaison Freed; rets-dev at rets.org
Cc: pobrien at ronintech.org
Subject: RE: [Rets-dev] RETS2 MLS Payloads for Vote on December 7th

> Photo Count and Photo Timestamp, the number of photos stored in the
MLS system for that listing and the most recent timestamp for the
photos.  In my experience almost every RETS client wants to see fields
with this information. 

I haven't read the whole doc yet, but to add to Jaison's comment above,
these two items are almost critical for IDX.  If your goal is to have
photos for all on market listings synched, having the photo synching
process just query for what photo timestamps have updated in the last x
hours, and only re-download those photos, is efficient.  An alternative
method is to assume that you need to get all photos every time a
listings Modified Date gets updated, but that's inefficient to the
server since the listing data may have changed but the photos may not
have changed.

Dan Woolley
Vice President of Technology
www.eneighborhoods.com

-----Original Message-----
From: rets-dev-bounces at rets.org [mailto:rets-dev-bounces at rets.org] On
Behalf Of Jaison Freed
Sent: Thursday, November 30, 2006 1:18 PM
To: rets-dev at rets.org
Cc: pobrien at ronintech.org
Subject: Re: [Rets-dev] RETS2 MLS Payloads for Vote on December 7th

Hi All,

I'm only on the rets-dev/rets-announce mailing lists, so I might have
missed some of the discussion up to this point if it took place
somewhere else.  That said, here are my initial thoughts after a quick
review of the Payload documents.

Agency.xsd:
Agency - Looking at the Offices.xsd and Agency.xsd files, I'm a little
confused about Agency.xsd.  It seems to be geared towards Agent
information, so why is named Agency?  Couldn't we follow the way Offices
is defined and have Agency be called Agents?  That is what it is a
collection of, isn't it?  To me it seems less confusing to use Agents.
Offices and Agency seem to be fairly interchangeable words for meaning
the same thing -- and in this case they don't mean the same thing.

Agency:Agent - How about adding a Designations field? (ABR, CRB, CRS,
e-PRO, etc)

Prospect.xsd:
Prospect - I don't think I'm getting this Payload.  I think of Prospect
to mean an Agent's clients and searches related to these clients.  While
the searching portion of prospects seems to be addressed, wouldn't 3rd
party products want contact information for these prospects as well?  Am
I correctly understanding the intentions of this Payload?

Listing.xsd:
Listing:ListingStatus - I don't see anything for storing Contingency
information.  Most of our clients will flag a Pending listing with
various Contingencies (home inspection, financing, etc).  To be generic,
it probably doesn't need to be a flag like we use but does anybody else
agree that Contingency information should be included in the Listing
definition?

Photo Count and Photo Timestamp, the number of photos stored in the MLS
system for that listing and the most recent timestamp for the photos.
In my experience almost every RETS client wants to see fields with this
information.

Listing:Disclaimer - I'm sure this is a bad idea for some reason or
another but I'd think it more efficient to put the Disclaimer in the
Listings object instead of in the Listing object.  Mainly just so you
only have to do it once and all of the records in the data are covered
as opposed to putting it as an element in each and every Listing record.
I'm guessing "the Lawyers" have deemed it necessary to put in every
single Listing record?

Well, those are my initial thoughts.  Anyone else?

Thanks,
Jaison

---
Jaison Freed
FBS Data Systems
3415 39th St S
Fargo, ND 58104
jfreed at fbsdata.com
701-235-7300 x146

On Nov 28, 2006, at 1:32 PM, Paula OBrien wrote:

> Many of you have been involved in the process to define MLS Payloads 
> for RETS2, through workgroups, comments on rets-dev, and outreach 
> efforts.
>
> The payloads have been updated to reflect all participation to date, 
> and are now available for comment through Sunday, December 3rd.  
> Comments will be addressed and payloads amended for voting on December

> 7th in San Diego.
>
> The payloads can be found at:
> http://retsserver.realtors.org:8080/xsd/index.html
>
> Please post your comments to rets-dev and cc me at 
> pobrien at ronintech.org.
>
> Thank you for your participation in this effort!
> _______________________________________________
> 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
*** eSafe scanned this email for malicious content ***
*** IMPORTANT: Do not open attachments from unrecognized senders  ***

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