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

[Wantao Zhou]

Currently the Vocabulary serves two purposes. One is to provide dialects
to the field names. The other is to restrict the availability of fields
based on role based security. However, we really need to think carefully
whether it should be the responsibility of Vocabulary to serve both
purposes.

If the actual intention of breaking out Vocabulary is to allow
personalized metadata and to reduce redundant metadata download, then
Vocabulary shouldn't have a role in serving the first purpose. As a
matter of fact, the different dialects should be expressed in
DataDictionary because the dialects should be treated as attributes of
the fields. In this way, the Vocabulary can be very small and thin and
still be very effective in providing personalized metadata.

Wantao

-----Original Message-----
From: rets-dev-bounces at rets.org
[mailto:Steve.Clarke at FirstAmericanMLS.com] 
Sent: Thursday, May 18, 2006 8:32 AM
To: jbrush at ronintech.org; pstusiak at falcontechnologies.com;
rets-dev at rets.org
Subject: RE: [Rets-dev] RETS 2 Service Document posted to www.ftc2.com

Jeff, 

We can't forget that the "select" clause is also a portion of the query.
Not just the RQL part.  Also, I find it highly doubtful that a striking
R0043 would expand vocabularies by 10 times.  In our case it would be
more like by about half a percent.  After all, the vast majority of our
fields ARE searchable.

I guess I shouldn't really try to comment on what 'the' original intent
of vocabularies was.  But I do know what 'my' original intent was as I
really was the person that pushed for the vertical segmentation of the
dictionary metadata in this way.  The fact that somewhere along the
line, attributes from dictionary started sneaking into vocabulary is an
indication that somewhere along the line my intent was diverted.

On the unrelated topic, regarding DELIMITED payloads:  I do know they
were added back into the specification by (unpopular) demand.  But we
only added support for DECODED representations of data and not for
ENCODED data as was supported in RETS1.  

smc
 

-----Original Message-----
From: rets-dev-bounces at rets.org [mailto:rets-dev-bounces at rets.org] On
Behalf Of Jeff Brush
Sent: Thursday, May 18, 2006 11:16 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


At the risk of 'twisting' and defeating 'original' purposes let me
explain 
some of the rational behind R0043- the requirement that vocabularies
must be 
searchable.

The expectation for RETS2 is that most requests will be for XML
documents. 
This was true to the extent that the RETS community even voted to
exclude 
COMPACT from RETS2.

In the context of XML, the only field names that are relavent are thoses

used in the query clause. Does it make sense to at least quadruple (or
even 
10x) the size of all vocabulary document to support non-searchable
fields 
that will not be referenced.

In the case of DELIMITED payloads, DELIMITED data was added back into
the 
spec at the request of client-side users. The primary purpose was to
allow 
data replication. Because MLSs historically have a difficult time
mapping 
names other than system names to their data, we didn't feel the need at
this 
time to implement other vocabularies that have yet to be defined. (We
hope 
to identify a more optimal replication method in the future.)

A little perspective is sometimes helpful.

Jeff Brush
Chief Architect
Ronin Technologies



>From: Steve Clarke [mailto:Steve.clarke at firstamericanmls.com]
>Sent: May 18, 2006 6:28 AM
>To: Sergio Del Rio; Paul Stusiak; rets-dev at rets.org
>Subject: RE: [Rets-dev] RETS 2 Service Document posted to www.ftc2.com
>
>Yea.  I thought we called that a "vocabulary" too.  But in the current
>draft spec, that meaning (of vocabulary) has been twisted by R0043
which
>now attaches an inherent functional limitation (must be searchable) on
>the vocabulary fields.  That change now implies that we are
>substantially missing something from the metadata and it also creates a
>redundancy with the IsSearchable attribute in the dictionary.  In my
>mind, the fact that we even have an IsSearchable attribute in the
>dictionary validates the original intent of a vocabulary to be exactly
>what you are asking about.  Certainly that's what I thought too.  But
>R0043 kinda defeats the original purpose.
>
>Smc
>
>-----Original Message-----
>From: rets-dev-bounces at rets.org [mailto:rets-dev-bounces at rets.org] On
>Behalf Of Sergio Del Rio
>Sent: Wednesday, May 17, 2006 11:31 PM
>To: 'Paul Stusiak'; rets-dev at rets.org
>Subject: RE: [Rets-dev] RETS 2 Service Document posted to www.ftc2.com
>
>OK, I must be tired.  I thought it was there at some point, but now I
>can't
>see it.  What happened to the metadata tag concept that was going to
>reduce
>the amount of different metadata that we were going to have.  Did we
>replace
>this simply with different Vocabulary or Data Dictionary versions?
>
>Regards,
>Sergio Del Rio
>Templates 4 Business Inc.
>
>
>-----Original Message-----
>From: rets-dev-bounces at rets.org [mailto:rets-dev-bounces at rets.org] On
>Behalf
>Of Paul Stusiak
>Sent: May 16, 2006 3:02 PM
>To: rets-dev at rets.org
>Subject: [Rets-dev] RETS 2 Service Document posted to www.ftc2.com
>
>Changes for FC5
>
>1. Remove section 2.4
>
>2. Add requirement
>
>R0148	A Provider SHOULD return a fault when an invalid Field Name is
>used
>in a
>Query by the Requestor.
>
>and modify the text preceeding to clarify the behavior of Vocabulary
>under
>security and system reductions.
>
>3. Correct select statement for the Delimted ObjectType to use either
>the
>WellKnown Vocabulary field names or the DataDictionary field names.
>
>4. Update R0138 from presented to present
>
>5. Update R0139, adding the preamble "If DisplayGroups are present in
>the
>Vocabulary document," to the beginning of the document.
>
>6. Added a reference section pointing to the RQL Query Language
>documents.
>They
>are currently only available on the mirror site and not on rets.org.
>
>The document will be bookmarked and an index added after the final
vote.
>
>It is now posted to www.ftc2.com
>-----------
>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
>
>
>_______________________________________________
>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
_______________________________________________
Rets-dev mailing list
Rets-dev at rets.org
http://lists.rets.org/mailman/listinfo/rets-dev