FW: [Rets-dev] More about schema overrides

[Jeff Brush]

 Triple inline---

> -----Original Message-----
> From: Matt Lavallee [mailto:matt at pmptechnology.com]
> Sent: Monday, April 30, 2007 11:18 AM
> To: 'Jeff Brush'
> Subject: RE: [Rets-dev] More about schema overrides
> 
> 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?

Not exactly. XML Schema inheritance is derived from the existing type.
Specifically an IS-A relationship. This section refers to guidelines for
building your own schema. 

The section I was referring to was farther down at line 341 - '1.2.9.5
General extensibility Guidelines - Avoiding Non-Determinism'


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

Extension is different from redefinition. 
Allowing non-derived redefinition breaks semantic meanings.
An XML instance document with extensions can still be validated by the
standard schema. And tools built from the standard schema can process the
standard portion of the instance.

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

In my mind the point of having a data standard is to leverage the
commonalities between systems. Having common names without common types has
been an issue for some RETS data consumers actually hindering adoption.

If the bulk of the data is very different and cannot be mapped to the
'standard' schema types, it maybe best not to use the 'standard' and define
a local market standard schema. I personally think there is nothing at all
wrong with that as long as it satisfies the consumers. 

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

But handling a 'Huge' value for TotalArea will force every client to handle
that special case for this MLS anyway unless this is the only MLS the client
talks to. In that case a data standard does not really matter and a 'local
standard' is sufficient. 

I think the best we can do is agree to disagree. 

Jeff