[Rets-dev] Email validation regular expression

Fri Apr 27 09:39:42 CDT 2007

I think the whole blog thing is a little weird.  The conversation belongs on
the dev list.  The lack of standardization has a history behind it and
sometimes it is political.  It is still a little early in the process to
become the righteous one.

Stuart

-----Original Message-----
From: rets-dev-bounces at rets.org [mailto:rets-dev-bounces at rets.org] On Behalf
Of Steve Clarke
Sent: Friday, April 27, 2007 10:18 AM
To: Michael Wurzer; Rets-dev at rets.org
Subject: Re: [Rets-dev] Email validation regular expression

I took some offense to your blog because I think I fell into your
generalization of "those against standardizing the data..."  I think
that is totally misrepresentative of my position. 

I'm not sure if it's intentional, but the term "data standardization" is
not made entirely clear in your blog because we really should make it
clear that there are two aspects:

1) Standardizing the fields to the point where we have known/common
field names that everyone agrees to their meaning.  

2) Enforcing strict data validation to the point where all data is
represented in exactly the same way.  

Those that oppose tight coupling of the two aspects should not be
categorized as being "against data standardization."  Of course "data
standardization" is a good thing and most everyone that you ask will
agree.  I would not classify myself as being "against standardizing the
data."  As an MLS vendor, I have no agenda to oppose data
standardization.

My point is that if we employ rigid data validation in the specification
with no flexibility, then it means that existing systems will not be
able to use the standard payload fields and will therefore have to
implement payload extensions for fields that SHOULD HAVE been mapped to
the standard fields.  The result would be a bunch of compliant RETS
servers that provide minimal data standardization and heavy use of
extensions to the standard payloads.  

I am NOT against data standardization.  In fact I can state that I am
trying to support data standardization by attempting to make sure that
it has a chance to be viable in our standard.  The 1.x standard has
failed in the sense that the practical use cases are almost exclusively
NOT using the standardized fields.  

My comments at the conference were centered around coming up with a way
to support DUAL levels of validating schema.  The first level would be
to validate the payload only structurally (the fields) and the second
level would validate the data elements.  The second level of validation
would (at least initially) be optional and a server that can provide a
standard payload that DOES NOT meet the strict data validation
requirements would still be compliant.  That recommendation did not gain
any traction because the notion of maintaining dual validating schemas
would be "hard"...

So I would say that those that are trying to tightly couple "data
validation" with "data standardization" are actually the ones that are
"against data standardization" because they are detracting from the most
important effort of standardizing the fields and are rendering "data
standardization" impractical at the present time.  I don't want to spend
hours discussing the RE to validate an email address.  I'd rather just
make EmailAddress a standardized field and move on.

smc

-----Original Message-----
From: rets-dev-bounces at rets.org [mailto:rets-dev-bounces at rets.org] On
Behalf Of Michael Wurzer
Sent: Friday, April 27, 2007 9:05 AM
To: Rets-dev at rets.org
Subject: Re: *SPAM* Re: [Rets-dev] Email validation regular expression

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
>
_______________________________________________
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