[Rets-dev] More about schema overrides

Sun Apr 29 12:33:45 CDT 2007

Why are we even discussing the possibility that a standard should be
so robust that it can create an all-powerful client that doesnt need
any external intrevention to take data from one end and bring it over
to the other?

I'm back to the concept of RETS being the transport mechanism.  Build
a second application that takes the payload and does something with it
- ie a Mapping Agent.  That second application can have the logic on
data purity.  If my app doesnt mind a varchar 64 PhoneNumber field,
then so be it.

I would like to see RETS define the delivery and the stadnrad named
fields, not the content, form or function of what I can do with that
data.

Im gonna have to build a mapping agent anyway, so let the client get
the data, and let me process it on my own.  You can work for the next
10 years on this concept if you want, is it so hard to just break
transport from end-use?

On 4/29/07, Jeff Brush <jeffbrush at hotmail.com> wrote:
>
> Matt,
>
> Doesn't allowing anything into a field/element cause "a whole new level of complexity for consuming clients" anyway? Unless your MLS is the only MLS the client communicates with, the client code is going to have to code around possibly having a "Huge" area value anyway.
>
> The original intent behind the extensibility of the proposed payload formats is NOT to override element types, but to create new elements in their own namespace that provide their own semantics. "Huge" is either a description, if it is free form, or a category, if it is an ordered, enumerated type, and in either case, deserves its own element. It would not map to '<TotalArea>'.
>
> The biggest re-occurring stumbling blocks RETS has had over its lifetime is its inability to agree on standardized names and types. Stonewalling by a vocal minority has prevented RETS from setting a true data standard, which can at least be used as a goal. If your data fields are so completely different from the data elements in the 'standard payload', RETS2 encourages an MLS or group of MLSs to extent the defined schemas with new elements, create their own XML schemas or even develop totally new types of data payloads.
>
> Perhaps there needs to be goal of trying to satisfy 80-95% of the data requirements of the community instead of unobtainable perfection.
>
>
>
> Jeffery A. Brush
> Ronin Technologies, Inc.
>
> "I saw it with my own eyes, and heard it with my own ears, and part of it fell on my head!" - Chicken Little
>
>
>
>
>  ________________________________
 From: matt at pmptechnology.com
> To: Rets-dev at rets.org
> Date: Sat, 28 Apr 2007 17:10:46 -0500
> CC:
>
> Subject: [Rets-dev] More about schema overrides
>
>
>
>
> I want to clarify my earlier statement as to why I don't like local schemas.
>
>
>
> First, consider that we will have a pseudo-definitive RETS2 schema that makes strict type assertions such as:
>
>
>
> <xs:complexType name="Area">
>
>        <xs:simpleContent>
>
>               <xs:extension base="xs:decimal">
>
>                      <xs:attribute ref="commons:areaUnits" use="optional"/>
>
>               </xs:extension>
>
>        </xs:simpleContent>
>
> </xs:complexType>
>
>
>
> This enforces that the data held in an element using the type "Area" must be an 18-digit number with an arbitrary decimal point (i.e., numeric), and may optionally be labeled with areaUnits.
>
>
>
> Now, my MLS has dirty data in an element that maps to this type (BuildingArea).  In order to properly validate, my MLS would create their own schema that redefines the type.  Note that there are a couple of ways to do this,  but I'm going to use the cleanest method:
>
>
>
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
>
>        <xs:complexType name="MLSNIArea">
>
>               <xs:simpleContent>
>
>                      <xs:extension base="xs:string" />
>
>               </xs:simpleContent>
>
>        </xs:complexType>
>
> </xs:schema>
>
>
>
> Now, in their payload, they will need to include that local schema and declare the namespace for the element's type (again, I'm using what I consider to be the cleanest method to do this):
>
>
>
> <?xml version="1.0"?>
>
> <rets2 xmlns="http://www.ftc2.com/xsd/RETSCommons/2007-04"
>
>        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>
>               xsi:schemaLocation="http://www.mlsni.com/xsd/RETS2
>
> http://www.mlsni.com/xsd/RETS2.xsd">
>
>
>
>        <Properties>
>
>        <Property>
>
>                      <TotalArea xsi:type="mlsni:MLSNIArea">HUGE</TotalArea>
>
>               </Property>
>
>        </Properties>
>
> </rets2>
>
>
>
> … and, voila, their payload now validates!
>
>
>
> But what really happened is that I dissolved the standard and created a whole new level of complexity for consuming clients.  Note that the "TotalArea" element is no longer what was defined by the spec.  In result, we may as well say that every field is arbitrary anyway, since a consuming client can't trust the core RETS2 schema… and that's the part that I really don't like.  They could just as easily add:
>
>
>
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
>
>        <xs:complexType name="MLSNIArea">
>
>               <xs:sequence>
>
>                      <xs:element name="personWhoMeasured" base="xs:string" />
>
>                      <xs:element name="dateMeasured" base="xs:date" use="optional" />
>
>                      <xs:element name="areavalue" base="xs:integer" />
>
>                      <xs:element name="areaunits" base="xs:string" />
>
>               </xs:sequence>
>
>        </xs:complexType>
>
> </xs:schema>
>
>
>
> … at which point we can't rely on the RETS2 spec at all.
>
>
>
> Alternatively, the even worse form of override would be to redeclare the element itself (say MLSNITotalArea), in which case the client wouldn't even know what field to look for without a roadmap and compass.  The document would still validate, but would be well outside the intention of RETS2.
>
>
>
> With 54 current schemas and a seemingly infinite number of local types declared in the spec, it would be a herculean task to get a client working reasonably with even 5 MLSes that had local data anomalies, mapping hundreds of types to a unified set.
>
>
>
> Painless: strict vs. loose
>
> Instead, by allowing a "loose" schema that does not specify types and a "strict" schema that does, we would allow the consuming client (even if it's another MLS) to always know and trust the structure.  Moreover, a locally-declared schema, should an ambitious MLS take the initiative, would be a "type hinting" bonus rather than an implementation hindrance.  I also think it'd be a great idea for us to include a "MUST" format for how such local schema should be included, what they can redefine, etc… particularly as it pertains to the security model.
>
>
>
> Moreover, and quite possibly most importantly, the adoption of RETS2 would be a painless exercise.  Instead of having to break out giant datatype maps and spend precious man-hours trying to fit a square peg into a round hole, they could simply map local MLS fields to the RETS2 (i.e., true standard) fields and have an interface up inside of a week… while consuming clients can keep their existing data definitions intact.  All the while, the spec would provide guidance to the MLSes (and vendors) that the RETS2-strict format is the ideal.
>
>
>
> -Matt
>
>
>
>
>
>
> PMPTechnology.com
>
> Matt Lavallee
> Manager of Web Services
>
> phone: 630-598-2301
> fax: 630-982-6641
>
>
>
>
> ________________________________
Discover the new Windows Vista Learn more!
> _______________________________________________
> Rets-dev mailing list
> Rets-dev at rets.org
> http://lists.rets.org/mailman/listinfo/rets-dev
>
>