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

[Steve Clarke]

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rets.org/pipermail/rets-dev/attachments/20060516/8f42d753/attachment.html