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

Thu Nov 30 14:21:03 CST 2006

Matt, all,

Good call.  I completely missed the Media element that is part of the  
Listing definition.  I think this would likely address the Photo  
Count concern as there would be a MediaItem for each photo (or  
document, movie, etc) attached to a listing.  But, I don't believe I  
saw any child elements of the MediaItem object to be used for  
Timestamp information.  I think that if a dateTime element could be  
added somewhere to the MediaItem (or it's component elements) object,  
the Photo Timestamp issue would be covered.  Or, am I missing that too?

Thanks,
Jaison

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

On Nov 30, 2006, at 1:40 PM, Matt McGuire wrote:

> 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
> _______________________________________________
> Rets-dev mailing list
> Rets-dev at rets.org
> http://lists.rets.org/mailman/listinfo/rets-dev