RETS Change Proposal 31: Update Warning Block Enhancement
Author: Sergio Del Rio
Organization: Templates 4 Business, Inc.
Telephone: (604)529-1544
Address:
Email: sergio.del.rio@t4bi.com
Status: Proposal
Date: 03/24/2003
Proposal Version: 1.0
1. Synopsis
This change request will enhance the server's ability to maintain an audit trail of non-fatal rule violations by enhancing the Update Transaction. This enhancement will allow the server to indicate which warnings require end-user feedback and will allow a client to provide this feedback to the server.
2. Rationale
Many servers that implement the Update Transaction require support for warnings in addition to errors. Warnings are generally used to indicate that a rule violation has occurred that was not fatal and did not prevent the record from being saved into the database. While the current approach is sufficient for many implementations, most specifically a batch update program, it does not allow for a warning to be acknowledged by an interactive end-user in any way.

n some environments, it is required that an end-user provide a valid reason for having violated certain warnings.

To support this common business situation, it is proposed that a warning block be added to the Update Response Body Format that will give the server a clear way of indicating warnings separately from errors. Additionally, a new request argument is proposed for the Optional Request Arguments section. The new request argument will be called WarningResponse. It will allow a response to be provided by an end-user.

3. Proposal
This proposal affects several sections of the Update Transaction as follows.

3.1 Add warning-block to the Update Response Body Format

The warning-block is designed to allow the server to send back warnings (errors which will not prevent a record from being saved to the database). For consistency, it will be created identically to the error-block with the addition of a single field.

The warning-block is defined as follows:

warning-block ::= <WARNINGBLOCK>CRLF
                 1*(<WARNINGDATA>field<delimiter>warning-
num<delimiter>warning-offset<delimiter>warning-text<delimiter>response-
required</WARNINGDATA>CRLF)
                 </WARNINGBLOCK>CRLF

A Warning Block is returned when there is a problem with one or more of the fields that did not prevent the record from being saved to the database. It contains the field name, a warning number, some additional text about the warning (warning-text), where in the field data the warning occurred (warning-offset) and an indicator whether an end-user response to this warning is requested or required. The delimiter will be the same delimiter as the one defined for the error-block.

field ::= SQLFIELDNAME

This is the field name that generated the warning.

warning-num ::= 1*5DIGIT

This is the host warning number. This number, along with the warning-text, MAY be displayed to an end-user when looking at the corresponding field in the client application.

warning-offset ::= 1*5DIGIT

This is the offset into the field data that was sent by the client application to the server. It indicates at what character in the field data the problem was encountered. This number is set to zero ("0") if the offset of the error is unknown.

error-text ::= *256ALPHANUM

This is the warning text generated by the host to assist an end-user in determining the problem with the field data. This text is associated with the warning-num.

response-required ::= 0 | 1 | 2

This indicates whether an end- user response to this warning is requested or required as follows:

    0-No response is requested
    1-A response is requested
    2-A response is mandatory

If the response is mandatory, the client MUST send the end-user response for the specific warning-num in the WarningResponse request argument in order for this record to be successfully saved to the database.

3.2 Add WarningResponse to the Optional Request Arguments

This is a key-value pair indicating the responses which were provided for each warning-num that had the response-required field set to 1 or 2.

The key-value MUST be formatted as follows:

warning-num = warning-response *(field-delimiter warning-num = warning-response)

The definitions of the key-value pair fields are:

warning-num ::= 1*5DIGIT

This is the host warning number that was returned in the Update Response Body Format.

user-response ::= *256ALPHANUM

This is the text that the end-user entered in response to the specified warning. If a warning-num has been indicated as a response required of 2, then this string MUST NOT be null.

3.3 Additional Reply Codes

20211 WarningResponse was not given for all warnings that indicated a response-required value of 2.

4. Development Impact
Development impact depends on each current RETS client and server implementations, but should not have any impact on future RETS client and server implementations. Each existing RETS server and client, prior to passing of this proposal, have the option to change accordingly to be RETS compliant. Future RETS server and client implementation after approval of RETS 1.5 MUST follow RETS 1.5 standard.
5. Compatibility
Servers that do not send back any warning-block will remain backwards compatible to the existing RETS 1.0 specification and can continue to function and be considered RETS 1.5 compatible. It is not mandatory for a server to send back a warning-block.
6. Proof/Need of Concept Examples
None.