Search

RETS Change Proposal 5: Forward-Compatible Metadata Extension Mechanism
Author: Leendert M. "Leo" Bijnagte
Organization: Fidelity National Information Solutions
Telephone: (612)661-1087
Address: 100 Washington Ave. South #900, Minneapolis, MN 55401
Email: leob@vistainfo.com
Status: Proposal
Date: 01/24/2002
Proposal Version: 1.0
1. Synopsis
A change to the metadata DTD is proposed to allow for some types of future extensions without requiring further changes to the DTD.
2. Rationale
The current RETS Metadata DTD is specific to Version 1.0 of the standard. When new metadata fields are added in future versions of the standard, clients using validating parsers will break because they will encounter unexpected elements in the DTD. This proposal adds an <extension> tag to the existing DTD so that future extensions will not change the document type definition.
3. Proposal
3.1 Specification Changes

A new element is added to the Metadata DTD:

<!ELEMENT extension ANY>
<!ATTLIST extension
    Name CDATA #REQUIRED
    Type CDATA #REQUIRED>

This element is added to the top-level definition of each of the existing metadata types.

3.2 Implementation Notes

Future extensions to any Metadata type will add no new elements to the DTD. Instead, the extension will be included as an element of type Extension, with its name and type given as attributes of the Extension element.

This proposal does not include a mechanism for adding new metadata types to the DTD. Since the addition of new metadata types generally implies significant changes to program logic, and since entirely new metadata types are expected to be added only rarely, allowing top-level extensibility is not viewed by the program authors as justifying the additional implementation effort required.

4. Development Impact
The extension proposed amounts to a new way of representing metadata within the DTD. This will require changes to the semantic processing of the metadata DTD in order to access any future metadata extensions. However, this will be a one-time change and there will be no further development impact with future metadata extensions.
5. Compatibility
This change involves a change to the metadata DTD. Clients that check metadata returns for validitity as well as well-formedness will report that the metadata from a server impementing this change proposal is incorrect. It is not clear how many client implementations actually check for a valid metadata return in addition to requiring a well-formed return; the proposal author belives the number to be small or zero.

The purpose of this change is to prevent such incompatibilities in the future; however, there is no way to avoid at least one incompatible change during the transition.

6. Proof/Need of Concept Examples
None.