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

[Steve Clarke]

>> the metadata to list non-searchable non-local(system) fields 
>> has not been created yet.

Wow!  I actually thought this had already been defined (Vocabularies).
I was not aware that the specification was missing a crucial section of
metadata.

What is the reason that a Vocabulary has to carry an implicit limitation
to the functionality of a field?  

smc

-----Original Message-----
From: rets-dev-bounces at rets.org [mailto:rets-dev-bounces at rets.org] On
Behalf Of Jeff Brush
Sent: Wednesday, May 17, 2006 8:47 AM
To: Steve Clarke; pstusiak at falcontechnologies.com; rets-dev at rets.org
Subject: RE: [Rets-dev] RETS 2 Service Document posted to www.ftc2.com

Actually, it IS the field's existence in a Vocabulary that makes it 
searchable. The DataDictionary metadata, if it exists, should agree that
the 
field is searchable.

While the DataDictionary lists the local names, the metadata to list 
non-searchable non-local(system) fields has not been created yet.

Jeff Brush
Chief Architect
Ronin Technologies

>From: "Steve Clarke" <Steve.clarke at firstamericanmls.com>
>To: "Steve Clarke" <Steve.clarke at firstamericanmls.com>,"Paul Stusiak" 
><pstusiak at falcontechnologies.com>, <rets-dev at rets.org>
>Subject: RE: [Rets-dev] RETS 2 Service Document posted to www.ftc2.com
>Date: Tue, 16 May 2006 19:11:36 -0400
>
>It's the IsSearchable attribute in the dictionary that determines if a
>field is truly searchable (i.e. allowed to be used in the RQL query
>portion of the search transaction).  It's not the fields' existence in
>the Vocabulary.
>
>
>
>smc
>
>
>
>________________________________
>
>From: Steve Clarke
>Sent: Tuesday, May 16, 2006 7:07 PM
>To: 'Paul Stusiak'; rets-dev at rets.org
>Subject: RE: [Rets-dev] RETS 2 Service Document posted to www.ftc2.com
>
>
>
> >> 3. Correct select statement for the Delimted ObjectType to use
either
>the
>
> >> WellKnown Vocabulary field names or the DataDictionary field names.
>
>
>
>Nope, I think that change #3 would actually introduce more problems.
>Change #3 is actually a functional change to the specification and I'm
>looking for simply a clarification of the specification.  To require
the
>RQL portion of the query to only use fields from the specified
>Vocabulary, but then to allow mixing dictionary and vocabulary fields
in
>the "select" part of the query makes things even more complicated.
>
>
>
>What I'm looking for is a clarification of the term "searchable" in
>R0043.  It does not really necessarily mean that a field is legal in
the
>RQL portion of the query.  It only means that the fields can be used to
>construct a query (either the RQL or the select or both).
>
>
>
>Instead of "searchable" we should say something like "available to the
>search transaction".
>
>
>
>smc
>
>
>
>
>
>-----Original Message-----
>From: Paul Stusiak [mailto:pstusiak at falcontechnologies.com]
>Sent: Tuesday, May 16, 2006 6: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


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