*SPAM* Re: [Rets-dev] Email validation regular expression
Michael Wurzer
mwurzer at fbsdata.com
Fri Apr 27 08:04:33 CDT 2007
FYI, to expose this issue to our MLS clients and others, I posted about
it today on the FBS Blog (http://www.flexmls.com/blog). Your comments
are welcome.
For some background on why FBS is advocating data standards, you also
might find some of our earlier posts interesting:
Death of the MLS (http://www.flexmls.com/blog/?p=22);
Raging Regionals (http://www.flexmls.com/blog/?p=23); and
Regionals, Part II (http://www.flexmls.com/blog/?p=26).
Michael Wurzer, FBS
dsrockets at gmail.com wrote:
> Unless the data server vendors agree on data normalization on the
> backend (MLS Data Server Level), RETS can only be a transport as said
> earlier. yes, schema on a field level needs to be 'data standardized'
> but it can't go as far as the data level for the simple mantra
>
> 'crap in, crap out'
>
> if RETS is going to have a validation level or data that is
> intrinsically going to be invalid (reference the phone example: (212)
> 555-1212 call after 5), the the validation will simply be unused, or
> too stringent.
>
> Get the base done and add the extras as needed. Don't over build
> something trying to predict every use case. That'll lead to bloat,
> annoyance, and overlooking of the finer details to actually make
> something useable and efficient.
>
> Unless of course the vendors are going to standardize on the input of
> data from their own mechanisms (UI) it is useless validating output
> data. If this talk is more about the update mechanism, then input
> validation should still fall on the server itself, and not RETS.
> Maybe have a way to return a validation error from the server to the
> client.
>
> All in all validation should not be RETS, it should be MLS data server
> specific. let their internals fuss with how data is stored.
>
>
> On 4/26/07, JP Fielding <jp.fielding at threewide.com> wrote:
>
> agreed. seeing what happens with something as simple as timezone as
> gmt in rets 1.x, i would suggest it is better to build a framework
> that is lenient (and where they can describe) rather than have rets
> prescribe.
> - Hide quoted text -
>
>
> On 4/25/07, Sergio Del Rio <Sergio.Del.Rio at t4bi.com> wrote:
>
> I'm just saying it should be done 'after' we get agreement on the
> schema.
> >From what I have heard, it is currently very impractical to
> tighten up
> things to the data type level, let alone the format level. There
> are many
> issues with trying to force format masks for a phone number that were
> brought up at the meeting. If we put this kind of thing into the
> schema,
> the schema will very likely not be able to be validated. I just
> think that
> going to the format mask level is way too far to attempt. Let's do
> the data
> types and fields and leave it at that for the first round.
>
> Regards,
> Sergio Del Rio
>
>
> Templates 4 Business Inc.
> _______________________________________________
> Rets-dev mailing list
> Rets-dev at rets.org
> http://lists.rets.org/mailman/listinfo/rets-dev
>
More information about the Rets-dev
mailing list