RETS Change Proposal 16: Lookup Type Meta Update
|
| Author: Wantao Zhou |
| Organization: Interealty Corporation |
| Telephone: (604)422-2439 |
| Address: 7018 Lougheed Highway, Burnaby, BC V5A 1WC |
| Email: wantao.zhou@interealty.com |
| Status: Proposal |
| Date: 12/04/2002 |
| Proposal Version: 1.0 |
| 1. Synopsis |
This proposal makes the following changes in RETS 1.5 draft 1, section 11.4.3:
- Expand size of the LongValue field.
- Add usage guidance to the LongValue and ShortValue fields in Lookup Type metadata.
- Add a new optional identity field.
|
| 2. Rationale |
| The current standard defines three fields in Lookup Type metadata: LongValue, ShortValue, and Value. The standard further clearly specifies the Value field is "[t]he value to be sent to the server when performing a search". However, the standard only noted that the use of both LongValue and ShortValue fields are implementation-defined. The vagueness of the description for the two fields caused confusion on whether the values SHOULD be unique, and choices for selection and display. Also the current standard specifies both LongValue and ShortValue have maximum of 32 characters. The size of LongValue is too restrictive in practice and need to be expanded.
Client vendors are also looking for a persistent field in Lookup Type meta that can keep its value regardless changes of other fields when the meaning of the Lookup Type item doesn't change. This field serves as an identity of the Lookup Type item. None of the three fields currently specified in the standard is the best choice because of their potential volatility in the present usage scenario. |
| 3. Proposal |
| The Content Type of the LongValue field be modified to 1*100TEXT.
The Description of LongValue field be modified to read: "The value of the field as it is known to the user. This is a localizable, human-readable string. The values of this field do not need to be unique within one Lookup. A sample use of the field is for display in report."
The Description of the ShortValue field be modified to read: "An abbreviated field value that is also localizable and human-readable. The value SHOULD be unique within one Lookup. A sample use of this field is for selection in user interface."
Add a new optional identity column for Lookup Type:
| Field Name | Content Type | Descriptions |
| ID | 1*32ALPHANUM | The field identifies the Lookup Type item. The value of the field MUST be unique within one Lookup, and SHOULD not change as long as the meaning of the item doesn't change regardless changes of other fields. |
|
| 4. Development Impact |
| The increase of size restriction on LongValue allows server vendors to send more descriptive information about the lookup type item. Client vendors need to increase the string size for the LongValue field in code and UI layout.
Server vendors may need to modify the internal field mapping based on the additional description on LongValue and ShortValue fields.
Server vendors may need to return a unique ID field. Client vendors need to use this field to identify Lookup Type items if this field is available. |
| 5. Compatibility |
| Both server and client are required to support RETS 1.5. |
| 6. Proof/Need of Concept Examples |
| None. |