[Rets-dev] More about schema overrides

Tue May 1 14:53:52 CDT 2007

 In addition to just the 'server vendors', there are other groups that
should have a say in RETS decision making that should also be represented -
the MLSs themselves, and the actual RETS consumers: client vendors,
brokerages, etc.

> -----Original Message-----
> From: Stuart Schuessler [mailto:sschuessler at tds.net] 
> Sent: Tuesday, May 01, 2007 3:23 PM
> To: 'Steve Clarke'; 'Jeff Brush'; Rets-dev at rets.org
> Subject: RE: [Rets-dev] More about schema overrides
> 
> >>agree to disagree
> 
> While the new Governance model would certainly help there is 
> no reason a proposal for a change in direction cannot be 
> voted on at the future meeting.
> The only Governance at this point is a popularity vote.  The 
> quorum is not even defined.  If the group decides to change 
> directions there is no governance or even copyright that 
> prevents it from doing so.  I know that we had originally 
> voted to transition the RETS 1.x specification into the RETS 
> 2.x specification and somehow that was ignored.  Maybe we 
> should put ourselves back on track.  Maybe the people that 
> actually write production systems should be writing the 
> specification.  If server vendors do not step up and have 
> more say in the standard then they are stuck with what they 
> get- consultants defining their business.
> 
> Stuart 
> 
> -----Original Message-----
> From: rets-dev-bounces at rets.org 
> [mailto:rets-dev-bounces at rets.org] On Behalf Of Steve Clarke
> Sent: Tuesday, May 01, 2007 12:54 AM
> To: Jeff Brush; Rets-dev at rets.org
> Subject: RE: [Rets-dev] More about schema overrides
> 
> I think we need to do better than to agree to disagree.  This 
> is a fundamental direction of the RETS standards initiative 
> and we need to somehow get this decided.  Maybe we need to 
> get the governance group to show us how to resolve such 
> disagreements.  From my standpoint, there have been some 
> serious issues raised with the notion of strict data 
> validation being tightly coupled with the schema 
> standardization effort.
> The dissention is coming from a pretty diverse group of 
> people, and the concerns are very similar.  I would not be 
> satisfied if we all agree to disagree and then the standard 
> continues down this path with no resolution for the issues.  
> I believe there were some reasonable suggestions, not just 
> disagreement.
> 
> smc
> 
> -----Original Message-----
> From: rets-dev-bounces at rets.org 
> [mailto:rets-dev-bounces at rets.org] On Behalf Of Jeff Brush
> Sent: Monday, April 30, 2007 4:00 PM
> To: Rets-dev at rets.org
> Subject: FW: [Rets-dev] More about schema overrides
> 
> 
> 
>  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
> 
> _______________________________________________
> Rets-dev mailing list
> 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
> 
> 