Search

RETS Change Proposal 42: Custom-XML Format
Author: Bruce Toback
Organization: Office Products Technology, Inc.
Telephone: (602)996-8601
Address: 11801 N. Tatum Blvd., Ste. 142, Phoenix AZ 85028
Email: btoback@optc.com
Status: Proposal
Date: 10/24/2003
Proposal Version: 1.1
1. Synopsis
This proposal permits servers to offer and clients to request richer or more specialized custom XML data return formats, and provides a means for client discovery of those capabilities.
2. Rationale
The current RETS specification provides for only one type of XML data return: STANDARD-XML, which corresponds to the RETS DTD. MLS data providers wish to offer custom DTDs so that they can provide an XML view of their entire data set, something not possible with STANDARD-XML. In addition, RETS should not inhibit the sharing of data in other standard formats when there is an advantage to doing so. For example, a server may wish to offer data in a MISMO or Appraisal Institute format as an extra service. This proposal provides a standard means for doing so.
3. Proposal
3.1 Specification Changes
3.1.1. Search Transaction Changes

Section 7.4.2, the Format argument for the Search transaction, is amended to include:
1. A fourth format token, CUSTOM-XML, which be followed by a colon and a DTD identifier.
2. A description of the DTD identifier and how to obtain the list of DTD identifiers supported by the server.
3. An additional return code, 20515, indicating that the requested CUSTOM-XML format is not available.
3.1.2. GetMetadata transaction changes

A new type of metadata, METADATA-RETRIEVAL_FORMATS, is added to RETS. This metadata resides under the Class metadata in Figure 11.1, and contains the following columns:

NameTypeInterpretation
DTDIdentifierCharacterThe identifier to use in the CUSTOM-XML: token in order to obtain this format. If the DTD is a PUBLIC DTD, then this SHOULD be the public identifier.
TextDescriptionCharacterA text description of the DTD. This is intended for human interpretation rather than machine interpretation.
URLCharacterThe URL at which the DTD may be obtained. This is not required, but SHOULD be provided for any DTDIdentifier which is not public.

The purpose of this table is to allow a server to advertise any additional DTDs that are supported for a particular resource and class. A client wishing to discover the existence of support for a particular public DTD can do so by referring only to the DTDIdentifier field of the table.

4. Development Impact
The functionality described in this change proposal is optional, and is specifically intended to allow servers to offer additional capabilities. Therefore, there is no mandated development impact.
5. Compatibility
6. Proof/Need of Concept Examples
None.