[Rets-dev] Contemplations on RETS 2.0

[Steve Clarke]

I agree with Matt to a certain degree:  I too believe that the stricter
we make the data typing in the standard payloads, the more likely we
will see implementations that do provide less data elements in the
standard payload and instead more data in extensions to the payload.
This essentially bypasses the standard payloads (or dilutes its intent).
Looking at the current use cases of RETS 1.x, I think we know that very
few clients actually rely on the Standard Names aspect of the
specification.  In my mind, the standard payloads are no different.

Obviously, I disagree with Matt that we should essentially rely 100% on
standard payloads and that this would render our metadata obsolete.
Sure, this argument holds water, but to me it's more like a "devils
advocate" argument that is intended to get a reaction (like mine) of
"hey, wait a minute, we can't do that!"

>From a practical standpoint, we have MLS systems that will natively
deviate significantly from the standard payload structure (and even more
so from the strict data typing).  It is unrealistic to think that every
MLS will modify their data to fit the mold of the standard payloads.  It
is also unrealistic to think that MLS vendors will absorb the cost to
implement complex mapping and data translation layers (plus the tools to
support the mappings and the support overhead to maintain the mappings
as their native systems change) solely for the purpose of being able to
better fit the standard payloads.

...especially when the RETS standard does provide for the native MLS
data to be represented, described and queried in its native form by
using the resource metadata.   Beyond that, the ability for a client to
specify what fields they desire and retrieve them in a compact payload
are benefits that will make it even more difficult for the standard to
mandate a 100% standard payloads solution.

Finally, we still have the fundamental problem of what to do when the
native resources do not even match up to the standard payloads (e.g. An
MLS with multiple "Residential" property types).  The standard does not
describe what the server needs to do to support that situation.  I
suspect that if the specification requires that the server MUST somehow
combine the query, perform multiple searches and merge the results from
multiple property types there would be some resistance.  But without
providing some way to relate the native resources to the payloads (and
allowing the client to query against a native resource) it count render
unreliable results.

Steve Clarke

-----Original Message-----
From: rets-dev-bounces at rets.org [mailto:rets-dev-bounces at rets.org] On
Behalf Of Matt Lavallee
Sent: Friday, August 03, 2007 7:50 AM
To: 'Paul Stusiak'
Cc: rets-dev at rets.org
Subject: RE: [Rets-dev] Contemplations on RETS 2.0

To pare down the issue: RETS 2 payloads allow local extension (through
local
namespaces), and this has been a cited solution to defer the limitations
of
standard-defined enumerations (lookup lists).  However, many complex
type
definitions in the standard also permit local extension, including
Vocabulary.  A meta-meta structure is a kitsch way to refer to
structures
that describe data that describes data.

First, the payload corruptibility issue...

I understand the (intended) concept of the Payload data model
representing a
select view of the "resource" data model.  However, if the payload data
model is - as we've strived to achieve - reflective of the collected
genius
of the most complete Resource models, then one must ask if there is a
compelling need for the disparate models at all.  In other words, if
there
is a discrete 1-to-1 mapping between Payload and Resource (or so long as
Payload subsumes Resource), what is Resource's value?  This only seems
to
serve as a secondary mapping exercise for the MLS that is not (ever?)
directly addressed as a data source to the best of my knowledge (which
may,
in fact, be uninformed, hence this thread).

The REIL example goes back to the "decoded is not entirely decoded"
argument
posited months ago.  REIL chose to emit cities in the listing data as
keys
to another discrete Resource named Cities, and at no time can you (even
if
you're requesting "decoded" results) get the city name commingled with
the
Listing data.  In R2, if a vendor can emit an instance document that
uses a
local namespace to extend an existing type, then it may also be used to
"optimize" the data as they see fit at the output level and no longer
conform with the expected payload results.  This gives rise to
inconsistency
between systems and creates the fractured landscape we see with 1.x.

The flaw with R0104 is that virtually no MLS will support "all" of the
payloads (e.g., in their entirety), and the restriction does not state
that
they must support the standard schema in an unmodified form (this was,
after
all, the reprieve for systems that wanted to extend enumerations).
Should
they choose to emit an instance that uses a redefined (and extended)
version
of Properties.xsd in a local schema, there is no assurance that the
client
would ever receive the "standard" definition of a Property, even though
all
restrictions with respect to the standard have been met and the document
will validate against the proper (i.e., public RETS) namespace.

Second, DataDictionary & Vocabulary...

As I have come to understand these two structures, they are intended to
do
two things:

1. Provide a referential map between the Resource model and the Payload
model
2. Provide a globally-unique identifier to every leaf node in the data
space
(graph)

As noted above, if the Resource->Payload translation is transparent
(and,
therefore, superfluous), then #1 is satisfied.  Moreover, if the graph
can
be addressed in an self-evident manner (Listings/Listing/ListingStatus)
as
presented by the payload schema, then #2 is also satisfied.

Again, my intent is to ensure that the Standard describes the least
complex
method to convey our information in a precise and accurate manner.

-Matt


_______________________________________________
Rets-dev mailing list
Rets-dev at rets.org
http://lists.rets.org/mailman/listinfo/rets-dev