RETS Change Proposal 3: Global Structure Information
|
| Author: Bruce Toback |
| Organization: |
| Telephone: |
| Address: |
| Email: |
| Status: Proposal |
| Date: |
| Proposal Version: 1.0 |
| 1. Synopsis |
| This proposal adds several fields to the RETS 1.0 metadata specification to allow a client to find and exploit relationships between resources offered by a server. |
| 2. Rationale |
| RETS servers frequently make available resources that are interrelated. A simple example is the inclusion of agent information on a listing. Currently, there is no way for a client to understand these relationships except by guessing on the basis of RETML tag names and well-known resource names. This proposal adds fields to the TABLE metadata to make these relationships explicit.
The proposal does not require that clients make use of the information, nor does it require that servers make it available. However, a client that makes use of the information may be able to provide a richer data set to the user or optimize fetches from the server. |
| 3. Proposal |
| 3.1 Specification Changes
The following metadata fields are added to the TABLE metadata (Table 11-4 in the RETS protocol specification):
| Field Name | Content Type | Description |
| ChildResourceID | Character | The ResourceID (Table 11-2) of the resource that for which this field functions as a foreign key (if any). The name given MUST appear in the METADATA-RESOURCE table. |
| ChildResourceClassName | Character | The name of the resource class for which this field functions as a foreign key. This name MUST appear in the RESOURCE-CLASS table for the given ChildResourceID. |
| ChildFieldSystemName | Character | The SystemName of the field in the given resource class that should be searched for the value given in the this field. This name must appear as a SystemName in the METADATA-TABLE section of the metadata for the resource class, and the named item must have its Searchable and Unique attributes set to TRUE. |
If the server does not transmit values for all three of these fields, the client MUST operate as if it had received none of them.
3.2 Implementation Notes
When displaying data from a particular resoruce, a client MAY use the child resource information in the metadata to retrieve and display related records from other resources. It does so by creating a search on the specified resource and resource class using a simple equal-to query. There is no restriction on the content of this query, however, so the server should not anticipate any particular sequence of operations when it supplies child resource metadata. |
| 4. Development Impact |
| Because the changes described in this proposal are optional, there is no forced development impact. Server developers wishing to implement this change proposal need only transmit the new metadata fields. Client developers wishing to take advantage of the additional structural information may do so as they see fit. |
| 5. Compatibility |
| Because this change involves only optional metadata, there is no forward or backward compatibility impact from this change. Clients that implement this proposal but do not receive the optional metadata fields simply display or operate on the transmitted search results without further enhancement. |
| 6. Proof/Need of Concept Examples |
| None. |