[Rets-dev] RETS 2 Service Document posted to www.ftc2.com

[Wantao Zhou]

If Vocabulary is restricted to searchable fields only, how can the
Provider advertise different dialects for non-searchable fields?

Wantao

-----Original Message-----
From: rets-dev-bounces at rets.org [mailto:rets-dev-bounces at rets.org] On
Behalf Of Paul Stusiak
Sent: Tuesday, May 16, 2006 3:43 PM
To: Steve Clarke; rets-dev at rets.org
Subject: RE: [Rets-dev] RETS 2 Service Document posted to www.ftc2.com

Arrgh! Webmail is painful. I don't see my earlier response to this up on
the
rets-dev list, so I'm guessing that it has gone astray.

I believe that change 3 resolves the issue for you.

So here is what I said earlier. Sorry if you wind up with two copies:

---
The Vocabulary document is the list of fields that you can use in the
query
statement in the Search action. It is not the search fields. Hopefully,
the
change in the Vocabulary section, combined with the change in the
SearchRequest/Select description clarifies this.

In the case that you have described, the security you implement reduces
the list
of query fields by role. This would be reflected in the WellKnown
Vocabulary
having fewer field names than are in the WellKnown Names list. To form
the
select, you would use the  DataDictionary for the select element name
for the
fields that are not query fields.

I think that this fixes the case that you are describing.
----

Generally speaking, I would expect that new systems would lean more
towards the
full document model of processing, creating key-only payloads or
one-liner
payloads if this was really needed or custom payloads for specific
applications
that use a smaller set that the local system payload or the WellKnown
Names Payload.

I recognize that there are legacy systems that will want to behave
similarly to
RETS1, but this is a different, updated standard. We have, hopefully,
got it
close enough to satisfy those who want to move forward a little bit as
well as
those who want to move forward a lot. Remember, RETS2 does not simply
replace
RETS1. You could run both concurrently. The goal, of course, is to
migrate from
RETS1 to RETS2, taking advantage of the tools, libraries, XML and such,
but this
will not be overnight. Adding value will make this happen sooner, and
things
like XML have an operation and engineering cost associated with them
that need
to be considered in the equation to determine the pace that this occurs.

-----------
Paul Stusiak,
President,
Falcon Technologies Corp.
_______________________________________________
Rets-dev mailing list
Rets-dev at rets.org
http://lists.rets.org/mailman/listinfo/rets-dev