[Rets-dev] More about schema overrides

[dsrockets at gmail.com]

> RETS2 purposefully did this.

No it didnt according to you -

why are we/you/RETS trying to take the standard any further than a
payload delivery?  creating standardized data (do not confuse that
with standard field names) should not be (IMHO) a piece of RETS, maybe
a different standard under a RETS umbrella, but not something in the
transport definitions.

There is RETS Layer (maybe its a stand alone server - maybe not) and
there is the MLS Server.  If MLS server vendors want to work towards
data standards (again not Standard Naming for RETS payloads)  Then let
them work on that outside (or through another standard).

Data validation should be handled on the MLS server level - and as I
said earlier, maybe a a invlaid response during an update request.  If
the server has crap data (which of course is a matter of opinion on
the receiving party), then let the receiving party figure out what
they want to do.

If an update request passes invalid data, RETS shouldn't care, the MLS
Server should catch the error and return via RETS an error message,
thus letting the client know of the failure.  Why burden the RET
Standard on something that any well (ehem) written data storage sever
should be doing anyway.

I think that is all Matt and ,agreeingly, myself are saying here.

On 4/29/07, Jeff Brush <jeffbrush at hotmail.com> wrote:
>
> Dsrocket asks:
> "is it so hard to just break transport from end-use?"
>
The transport, aka service document
> -http://rets.org/files/RETS2_Service_final.pdf, is defined and accepted as a
> RETS standard. It allows the server to define whatever payloads it wants.
> The response is wrapped inside a SOAP 1.2 wrapper and sent via MTOM. SOAP
> provides for a common interface, security and error handling.
>
> Discussing and defining payloads will hopefully lead to well-known
> (standard) names.
>
>
> Jeff
>
>