[Rets-dev] Email validation regular expression

[Matt Lavallee]

Hi John,

Unfortunately, my MLS could not override the base definition of SecureInteger in
the RETS 2.0 schema.  They *could* extend the schema by providing an alternative
definition of the field itself (say, YearBuiltGoofyInteger), but then every
consuming client would likewise have to use THEIR definition of the "standard"
data field and not the common schema if they wanted to validate.  In other
words, we'd have hundreds of custom schemas to cover each MLS' uniqueness, and
wind up in the exact same boat we're in now with a different definition of
lookups.

Alternatively, and this is my prediction, they will go schema-less and present a
common structure to the data while ignoring the type restrictions altogether.

-Matt

> -----Original Message-----
> From: Walsh, John [mailto:John.Walsh at move.com]
> Sent: Wednesday, April 25, 2007 7:58 PM
> To: Matt Lavallee; Paul Stusiak
> Cc: rets-dev at rets.org
> Subject: RE: [Rets-dev] Email validation regular expression
> 
> Matt,
> 
> It is my understanding that the intent of the strong-typing is simply to
> give a potential outline of data that could be universally interpreted
> without having to know the specific context of the individual system.
> "YearBuilt" and its datatype would be known to be a valid year, and
> could be interpreted as such, which is why they are part of the base
> standard schema, RETS 2.0 out-of-the-box, as it were.
> 
> If your implementation requires a field with broader interpretation,
> than you can simply extend the schema to include a custom
> "YearBuiltOrAge" field, which would include both.  The beauty of RETS
> 2.0 is that the schema is extendible and doesn't lock you into a
> specific format, but rather gives you a suggested guideline.
> 
> Someone can correct me if I'm wrong on that, but so far I haven't seen
> anything that would completely back anyone into a corner with data
> format, as the extensible schemas give individual implementations the
> freedom need to get their data across.
> 
> -John
>