[Rets-dev] More about schema overrides

[Matt Lavallee]

Double-inline comments:


> > As I said before and others have raised throughout this conversation,
> > RETS is first and foremost a transport interface (contract) between
> > systems.  I would much rather have a reliable data structure than
> > validation rules that add 2-3 years to the MLS' adoption.
> 
> Then use the DELIMITED format. No data types are defined. No trying to
> force internal fields into typed XML elements.

1. May as well just wrap RETS 1.7 in SOAP and call it a day.
2. No movement to a common data structure.

> > The "intent of extensibility" is in no way documented, enforced by the
> > schema, and impractical to expect adherence by implementations.
> 
> The Resources and Payloads Document link-
> http://rets.org/files/rets2payloads.pdf on the rets.org site
> (http://rets.org/documentation) talks of this approach. It was a early
> document, mostly discussing the building of new schemas rather than
> extensions, but it does talk of this under extensibility. It does not
> suggest overriding types.

Lines 187-190:
	1.2.9 Creating Extensible Content Models
	If an existing type definition does not meet your exact requirements,
	you MAY use the XML Schema inheritance mechanism to define a new data
	type based largely on an existing one.

Sounds exactly like my example, no?

> Schema validation does prevent the override with the error: "cvc-elt.4.3:
> Type 'mlsni:MLSNIArea' is not validly derived from the type definition,
> 'Area', of element 'TotalArea'".
>
> And as for 'expecting adherence by implementations', it is either valid
> according to the schema or it is a different, non-'RETS standard' schema.

But if we're telling them to extend and/or redefine the schema, then they are
all non-'RETS standard' schema.
 
> > Why even have a structured standard at that point, if the expectation
> > is that each MLS is going to redefine it?  That's actually worse than
> > standard name lookups.
> 
> The point is there is no re-definition. It is an extension to a standard
> structure. There are common fields/elements to be handled in common ways
> and extensions to be handled(or not if the client doesn't care) with MLS
> (or regional or vendor) specific code.

So, if MLSNI is to ignore the TotalArea field (as you suggest) and define an
extended field (e.g., MLSNITotalArea), then every client will have to know to
use MLSNITotalArea instead of TotalArea... as far as I'm concerned, that's
redefinition of the standard, since the "standard" isn't at all "the standard"
in that market.  Also, as I pointed out earlier, this is far worse than the
existing lookup names system, since now I'm going to have to do this in every
single schema (with extension points), just to find out how to find what I'm
looking for.

-Matt