*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