[Rets-dev] More about schema overrides

Tue May 1 15:26:41 CDT 2007

Let me rephrase:

RETS 2.0 is a transaction management standard written by consultants that
have an interest in transaction management systems.

Is this a correct statement?

-----Original Message-----
From: rets-dev-bounces at rets.org [mailto:rets-dev-bounces at rets.org] On Behalf
Of Stuart Schuessler
Sent: Tuesday, May 01, 2007 4:22 PM
To: 'Sergio Del Rio'; 'Steve Clarke'; 'Jeff Brush'; Rets-dev at rets.org
Subject: RE: [Rets-dev] More about schema overrides

The focus of your email:  Transaction space.  Why?

RETS 2.0 is primarily a transaction management standard.

-----Original Message-----
From: Sergio Del Rio [mailto:Sergio.Del.Rio at t4bi.com] 
Sent: Tuesday, May 01, 2007 3:53 PM
To: 'Stuart Schuessler'; 'Steve Clarke'; 'Jeff Brush'; Rets-dev at rets.org
Subject: RE: [Rets-dev] More about schema overrides

This is all getting way out of hand...

How about we stick to the facts in these threads and keep the personal
comments out of them.

We have to realize a few points here:

1. The transaction space does have a need for standardized data types.  How
can we pass data from an MLS to a Mortgage system if the ListPrice field has
'Call Me' in it?  There are more examples, but I am sure you get the point.
2. The RETS 2.0 Payloads are the replacement for Standard Names in RETS 1.X.
In RETS 1.X, the Standard Names were almost never used because there were a
very limited number of fields and the lack of desire to do the mapping work.
There was a Data Dictionary workgroup put together for RETS 1.X that
eventually did come up with a list of Standard Names that everyone agreed
upon. The catch was, that the data types were flexible so that all systems
could more easily map their data. This would have resulted in the need to
consult the metadata for the actual data types.
3. There is the capacity in the RETS 2.0 work that we are doing, to provide
for many different schemas. There is already one proposed for IDX fields
that is not strongly typed, it is all strings and will likely satisfy the
easy data sharing of fields between IDX systems.  We could build others as
well.

So, why not address all the above requirements?  I don't think it will be
too much of a stretch to actually define all the data types for all the data
as we all think they should be.  The payload workgroup meetings should allow
this to happen.  The picklists, as long as they can be easily added to,
should also be workable.  Doing this exercise gives us the goal line.  There
are some other ideas that Paul has, that I hope he will share with us soon,
about how we can make the schema accommodate the kinds of issues we face
with point (1) above.  One we have the master schema set that defines the
data in the ideal way, we can then address new payloads that address data
type issues, much like the IDX payload definition.

Having the master schema that is strongly typed moves us towards the
transaction space as we all decided was a need when RETS 2.0 was proposed so
long ago.  Having the strongly typed schemas does not mean we cannot create
other schemas so that others can still use XML data feed.  Furthermore any
MLS system can define it's own XML schemas using this standard and if they
stick to the names defined in the standard schema, these will even be quite
workable for any client (perhaps we should add this as a requirement when
creating specific schemas).

For the MLS systems that don't want to play in the transaction space, they
can still use RETS 2.0 Compact format and provide metadata to clients that
define all the data types. This way, an intelligent and metadata-aware
client, can easily use the Compact data format and the metadata to build an
application that works across multiple MLS systems and RETS servers.

The way I see it, all is possible with the RETS 2.0 specification, so why
argue against a set of strongly typed schemas when they are truly what the
transaction space needs.  There are two other ways that clients can use the
RETS 2.0 specification and still be compliant.  It's simple, if you want to
move into the transaction space, that is the MLS motivation to map their
data properly to the strongly typed schemas.

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 Stuart Schuessler
Sent: May 1, 2007 12: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

_______________________________________________
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