RETS 2 Vocabulary intent WAS: [Rets-dev] RETS 2 Service Document posted to www.ftc2.com

[Paul Stusiak]

You are correct that it was not done at the April 13th meeting. It was done
earlier. LookupName and DataType and the subsequently removed LookupMap - an
inline version of the lookup reference are all in RC2. See table 18 and it was
present in the xsd. There was an error in the fragments that was subsequently
resolved.

The Vocabulary definition and samples of February 14th include the datatype. I
believe that it was added in January as an outcome of one of the calls.

In the earliest documents that I can find, Vocabulary has been related to the
request  criteria and not to the response or to the display.

As to resolving this in the future, I am not sure what to do here. Are you
proposing that we vote on each individual idea?

Information duplication should be permissible where it serves a purpose. In this
case, to make the metadata easier to use (and very, very few clients are using
metadata in RETS1), replicating the information seems reasonable.

Given that Vocabulary is related to the criteria and by definition, criteria
need to be searchable, I don't understand how removing "searchable" from this
makes it more clear.

Again, let me reiterate: Vocabulary relates to criteria, or in SQL terms the
WHERE clause. Letting users search on fields that are not searchable does not
seem like a good idea.

I will not be available for the next several hours.

Quoting Sergio Del Rio <sergio at mris.com>:

> I think what we are seeing here is an interpretation of Vocabulary from the
> April 13th meeting that was not the same for all parties that voted.  It is
> unfortunate, but clearly this is what has happened.  Not sure how these
> kinds of things can be totally avoided in the future.  Perhaps we should
> only vote on things that have a clear and written statement or
> mini-specification at meetings from now on...
> 
> I thought Vocabulary was added as a replacement for what we originally
> referred to as metadata tag or tag-id in previous e-mail threads and
> conference call discussions.  To me, this was to allow for different sets of
> field names to be communicated to clients for servers that wanted to allow
> clients to reduce the set of fields that they would get back from a request
> tailored by a user's server side roles.  This avoids errors where clients
> send queries for data that users are not allowed to see.  I thought we had
> agreement that this should be in the specification and I thought that we
> just renamed it to Vocabulary at the April 13th meeting.  The document did,
> in fact, imply that this is what Vocabulary was.  I really don't remember
> when we added LookupName and DataType to this, certainly this was not done
> at the April 13th meeting.
> 
> I don't think anything we are asking for is actually going to cause any
> major issues for any already developed software with the possible exception
> of removing LookupName and DataType from Vocabulary.  So, I guess we could
> live with leaving these in but we should at least take out the requirement
> that all fields be searchable.  However, leaving those fields in the
> Vocabulary, makes it larger than it was originally intended to be and it is
> duplicating data that is easily available elsewhere.
> 
> As for adding ENCODED, I don't see this as impacting existing code at all.
> 
> I thought this was still a 'Release Candidate' and that any developers
> working on this should be expecting to change some things.  I don't think
> anyone is being unreasonable here.  To suggest that we stop changing the
> specification because it has been coded to at this stage of the game is
> really not fair in my opinion.
> 
> Regards,
> Sergio Del Rio
> Templates 4 Business Inc.
> 
[snip]

-----------
Paul Stusiak,
President,
Falcon Technologies Corp.