[Rets-dev] Email validation regular expression

Thu Apr 26 07:58:16 CDT 2007

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.

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.
>
> -----Original Message-----
> From: Paul Stusiak [mailto:pstusiak at falcontechnologies.com]
> Sent: April 25, 2007 5:52 PM
> To: Sergio Del Rio
> Cc: 'Michael Wurzer'; rets-dev at rets.org
> Subject: Re: [Rets-dev] Email validation regular expression
>
> So we should ignore the unequivocal statement by the MLS staff in
> attendance at the last RETS Workgroup meeting in Austin to attempt to
> come up with type information and strengthen the data quality?
>
> Shouldn't we be trying to meet their needs?
>
> By my count, those MLS staff in attendance represented at least 250,000
> agents. While I know there was some concern voiced that the goal may be
> very difficult, we should at least try.
>
> None of them said "don't do it".
>
> So if they are willing, why shouldn't we try NOW?
>
> I would point to the un-sourced (if you know where it is from I'd like
> to know - that would be a book.) quotation attributed to Lucius Seneca:
> "It is not because things are difficult that we do not dare, it is
> because we do not dare that they are difficult."
>
> Maybe there is less of a problem than we perceive. Maybe I'll make this
> my sig...
>
> Paul
>
> Sergio Del Rio wrote:
> >
> > I'll have to third that motion, it is ambitious enough to get the
> > field values, let's save field content for 3.0...
> >
> >
> >
> > Regards,
> >
> > Sergio Del Rio
> >
> > Templates 4 Business Inc.
> >
> >
> >
> > *From:* rets-dev-bounces at rets.org [mailto:rets-dev-bounces at rets.org]
> > *On Behalf Of *Michael Wurzer
> > *Sent:* April 25, 2007 3:03 PM
> > *Cc:* rets-dev at rets.org
> > *Subject:* Re: [Rets-dev] Email validation regular expression
> >
> >
> >
> > Agreed.
> >
> > Michael Wurzer, FBS
> >
> > Steve Clarke wrote:
> >
> >         the balance between backward looking compatibility and forward
> >
> >
> >
> > looking uses.
> >
> > In my opinion we should be attempting to standardize the payloads to the
> > field level and not down to the data values.  If existing databases
> > contain "111-1234 (after 8:00 PM call 222-2345)" in a phone number
> > field, then does that mean that this phone number field can no longer be
> > mapped to the standardized phone field in the payload?  If a FloorType
> > field can contain a meaningful value that is not contained in the
> > enumerated list, does that mean that this can no longer be a floortype
> > field?  To me, this kinda defeats the objective of the standard
> > payloads.
> >
> > I think it's going to be hard enough to get practical use from the
> > standard payloads in RETS 2.0.  People are already asking how to use the
> > equivalent of COMPACT format in 2.0.  I don't think we should make it
> > even more difficult to adopt by enforcing rigid data value validation.
> > Or at least I think that the data validation should come after the
> > schema standardization has been accomplished and has been approved by a
> > critical mass of MLSs.
> >
> > smc
> >
> >
> >
> > -----Original Message-----
> > From: rets-dev-bounces at rets.org <mailto:rets-dev-bounces at rets.org>
> [mailto:rets-dev-bounces at rets.org] On
> > Behalf Of Paul Stusiak
> > Sent: Wednesday, April 25, 2007 5:34 PM
> > To: Keith T. Garner
> > Cc: rets-dev at rets.org <mailto:rets-dev at rets.org>
> > Subject: Re: [Rets-dev] Email validation regular expression
> >
> > While JWZ has many witty things to say, I think that there is some
> > question of Jaime as the originator of the quote (saw it earlier wrt to
> > sed/awk). See
> >
> > http://regex.info/blog/2006-09-15/247
> >
> > It is quite a good blog entry from a very experienced person using
> > regular expressions where he discusses the quote. You could also check
> > out the previous entry http://regex.info/blog/2006-09-14/246. He (JF)
> > wrote the MRE (no, not meals ready to eat - Mastering Regular
> > Expressions) O'Reilly book - something to while away the hours when
> > traveling to the next RETS meeting and an excellent example of technical
> >
> > writing. :-) It's hard to believe that it has been ten years since he
> > published the first edition. Looks like I'll need to get the updated
> > version...
> >
> > Also note that JWZ is an XEmacs/Lisp person and may have some religious
> > issues with regular expressions. Certainly some of the discussions
> > around Emacs, Lisp, Ruby and other languages, both in the past and
> > currently, should leave no one questioning how real wars start.
> >
> > The number of places where regular expressions can be used in RETS is
> > very small - properly. It is one of the "horses for courses" - pick the
> > appropriate tool for the task. We have more tools than a hammer, so we
> > don't need to treat everything as a nail. However, where there is a nail
> >
> > that needs to be pounded into a board, a hammer is much more useful than
> >
> > pounding the nail with a screwdriver or a saw (tried it, wasn't
> > pretty...)
> >
> > Of course, the "fully compliant" regular expression says volumes about
> > the standard (RFC 2822) and less about regular expressions. The RFC
> > attempts to make it possible to describe many very, very obsolete email
> > addressing schemes. It is something that should weigh heavily on us as
> > we develop standards, the balance between backward looking compatibility
> >
> > and forward looking uses.
> >
> > Paul
> >
> > Keith T. Garner wrote:
> >
> >
> >     As much as I find regular expressions useful, when I see something
> >
> >
> >
> > like the
> >
> >
> >     fully compliant regular expression, I have to quote JWZ.
> >
> >
> >
> >     "Some people, when confronted with a problem, think `I know, I'll
> use
> >
> >     regular expressions.' Now they have two problems." -- Jamie Zawinski
> >
> >
> >
> >     Keith
> >
> >
> >
> >     Matt Lavallee wrote:
> >
> >
> >
> >
> >
> >         Mostly for Paul's edification, this will pick up all
> RFC-compliant
> >
> >
> >
> > email
> >
> >
> >         addresses:
> >
> >
> >
> >
> >
> > [delete long regex]
> >
> >
> >         -Matt
> >
> >
> >
> >
> >
> >
> >
> >         pmpt_logo
> >
> >
> >
> >         PMPTechnology.com <http://www.pmptechnology.com/>
> >
> >
> >
> >
> >
> >
> >
> >         *Matt Lavallee*
> >
> >         /Manager of Web Services/
> >
> >
> >
> >         /phone:/ 630-598-2301
> >
> >         /fax:/ 630-982-6641
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> >
> >         _______________________________________________
> >
> >         Rets-dev mailing list
> >
> >         Rets-dev at rets.org <mailto: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
> >
>
> --
> Paul Stusiak
> Falcon Technologies Corp.
>
> _______________________________________________
> Rets-dev mailing list
> Rets-dev at rets.org
> http://lists.rets.org/mailman/listinfo/rets-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rets.org/pipermail/rets-dev/attachments/20070426/cdeae576/attachment.html