[Rets-dev] More about schema overrides

[Jeff Brush]

Actually, if it needs a label, RETS2 is a data repository service standard.
 



> From: sschuessler at tds.net> To: Sergio.Del.Rio at t4bi.com; sclarke at marketlinx.com; jeffbrush at hotmail.com; Rets-dev at rets.org> Subject: RE: [Rets-dev] More about schema overrides> Date: Tue, 1 May 2007 16:22:12 -0400> > The focus of your email: Transaction space. Why?> > RETS 2.0 is primarily a transaction management standard.> > -----Original Message-----> From: Sergio Del Rio [mailto:Sergio.Del.Rio at t4bi.com] > Sent: Tuesday, May 01, 2007 3:53 PM> To: 'Stuart Schuessler'; 'Steve Clarke'; 'Jeff Brush'; Rets-dev at rets.org> Subject: RE: [Rets-dev] More about schema overrides> > This is all getting way out of hand...> > How about we stick to the facts in these threads and keep the personal> comments out of them.> > We have to realize a few points here:> > 1. The transaction space does have a need for standardized data types. How> can we pass data from an MLS to a Mortgage system if the ListPrice field has> 'Call Me' in it? There are more examples, but I am sure you get the point.> 2. The RETS 2.0 Payloads are the replacement for Standard Names in RETS 1.X.> In RETS 1.X, the Standard Names were almost never used because there were a> very limited number of fields and the lack of desire to do the mapping work.> There was a Data Dictionary workgroup put together for RETS 1.X that> eventually did come up with a list of Standard Names that everyone agreed> upon. The catch was, that the data types were flexible so that all systems> could more easily map their data. This would have resulted in the need to> consult the metadata for the actual data types.> 3. There is the capacity in the RETS 2.0 work that we are doing, to provide> for many different schemas. There is already one proposed for IDX fields> that is not strongly typed, it is all strings and will likely satisfy the> easy data sharing of fields between IDX systems. We could build others as> well.> > So, why not address all the above requirements? I don't think it will be> too much of a stretch to actually define all the data types for all the data> as we all think they should be. The payload workgroup meetings should allow> this to happen. The picklists, as long as they can be easily added to,> should also be workable. Doing this exercise gives us the goal line. There> are some other ideas that Paul has, that I hope he will share with us soon,> about how we can make the schema accommodate the kinds of issues we face> with point (1) above. One we have the master schema set that defines the> data in the ideal way, we can then address new payloads that address data> type issues, much like the IDX payload definition.> > Having the master schema that is strongly typed moves us towards the> transaction space as we all decided was a need when RETS 2.0 was proposed so> long ago. Having the strongly typed schemas does not mean we cannot create> other schemas so that others can still use XML data feed. Furthermore any> MLS system can define it's own XML schemas using this standard and if they> stick to the names defined in the standard schema, these will even be quite> workable for any client (perhaps we should add this as a requirement when> creating specific schemas).> > For the MLS systems that don't want to play in the transaction space, they> can still use RETS 2.0 Compact format and provide metadata to clients that> define all the data types. This way, an intelligent and metadata-aware> client, can easily use the Compact data format and the metadata to build an> application that works across multiple MLS systems and RETS servers.> > The way I see it, all is possible with the RETS 2.0 specification, so why> argue against a set of strongly typed schemas when they are truly what the> transaction space needs. There are two other ways that clients can use the> RETS 2.0 specification and still be compliant. It's simple, if you want to> move into the transaction space, that is the MLS motivation to map their> data properly to the strongly typed schemas.> > Regards,> Sergio Del Rio> Templates 4 Business Inc.
_________________________________________________________________
Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy!
http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rets.org/pipermail/rets-dev/attachments/20070501/92caece4/attachment-0001.html