[Rets-dev] More about schema overrides

Tue May 1 00:19:43 CDT 2007

I would agree with you Steve, we need to resolve this.

The idea I liked so far was to have two schemas.  One that is used to
validate structure and MUST be used by ALL servers.  The other one becomes
the validation schema with data types in it.  The ultimate goal, of course,
is to get everyone eventually moved over to the validation schema with data
types, but this will take some time as all the MLS systems will have to be
able to adapt their data to fit the standard.

Yes, this means we have to keep two separate schemas up to date within the
RETS 2.0 documentation, but I do not see an alternative at this point.

Regards,
Sergio Del Rio
Templates 4 Business Inc.

-----Original Message-----
From: rets-dev-bounces at rets.org [mailto:rets-dev-bounces at rets.org] On Behalf
Of Steve Clarke
Sent: April 30, 2007 9:54 PM
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