Meeting Notes: June 2002

1. RETS Working Group Process
The attendees at the working group agreed to operate under the process as described in the meeting package (a set of slides describing the process is also available). The group will meet semiannually to review changes, with other business being handled by conference calls or, in rare cases where working groups require it, face-to-face meetings. (Two working groups were formed during this meeting.) A change approved at the meeting become part of the standard as of the date of the next semiannual meeting:

This process allows early adopters to work with standards changes as early as possible, with the risk (and the hope) that they will therefore ferret out any problems. More conservative developers can wait for final ratification before beginning coding.

2. Disposition of Errata and Change Proposals

• Errata #1, 2, 5, 9, 10, and 11 all refer to DTD enhancements. Leo Bijnagte stated that he had a number of DTD updates, including DTDs for history, prospect, tour and other resource types. There is a need for a "library" of DTDs or DTD pieces. Mike DelGaudio, Stuart Schuessler, Pete Clarno, Bill Detuno and Leo will hold a conference call to discuss Leo's changes/additions and make them ready for posting. The same conference will agree on the list of standard names required by erratum 3.

  Attendees noted a discrepancy in the interpretation of the term "history search". One interpretation was the change history for a particular record. The second is the history of a given property -- that is, a list of all prior known listings for that property. A second area that was unclear was the meaning of "tour" -- several attendees wanted to know how this differs from "open house". These issues will be resolved in the final DTD work product.

  It was proposed and supported that there be a "library" of DTDs or DTD fragments (an architectural decision to be made by the XML workgroup) for each well-known resource type. This isn't currently the case.

• Errata #4, 6, 7, and 8 are adopted.
• Change proposal #1 was rejected. However, it was agreed that we need a structure mechanism. Mike DelGaudio, Mark Lesswing, Sergio DelRio, Leo and Bruce Toback will constitute a workgroup to investigate this issue.
• Change proposal #2 was adopted.
• Change proposal #3 was rejected.
• Change proposal #4 was adopted, which several changes:

   1. Additional TABLE metadata fields are to be added. These indicate for each field in the table the key path -- the resource and key name -- from which they were obtained.
   2. The specification will state that implementations SHOULD provide a flat view of all data that the host implementation desires the client to present.

• Change proposal #5 was adopted.
• Change proposal #6 was postponed until the next meeting.
• Change proposal #7 was adopted, with an amendment to have the server respond to the login with a header indicating the highest RETS version that it's willing to accept. The returned error number will be changed to 20022.
• Change proposal #8 was adopted in principle. Several difficulties infelicities in the change proposal as currently specified will be corrected before incorporation; these have to do with asymmetrical treatment of string literals with and without quotation marks.
• Change proposal #9 was adopted, with Leo Bijnagte's addition to specify the computation of the cnonce.
• Change proposals 10 and 11 were tentatively adopted. They will be incorporated into the work product of the XML workgroup mentioned above. #10 was amended to include another attribute for each remark type: distribution, which can have either of the two values "public" or "private".
• Change proposal #12 was adopted, with the amendment that XML be well-formed rather than valid. Note that this requires that certain characters in request and response bodies be XML-escaped.

3. Revision Assignment and Compatibility
There was some disagreement over how to assign the above changes to different versions. In particular, it was not clear that the XML work could be completed by the end of the 8-week document editing window. This may be saved for a later 1.6 revision.

A question arose as to how to specify the level of backward compatibility between version of the specification. One suggestion is to change the specification item by item, deprecating and then removing on a case-by-case basis. Another is to specify that servers MUST support all minor revisions within a major revision (for example, a server that advertises itself as RETS 1.5 MUST support 1.0). This issue will need to be resolved on the mailing list. It will be easier once there is a new draft standard.

4. Additional New Business
ete suggested two change proposals to add to the specification. First, he notes that there is no method for requesting a sort of the downloaded data. This is important for thin clients that do not have local storage capability. Several server developers suggested modifications to the general concept so that the server could inform the client via metadata which fields can be included in a sort.

The second suggestion was to add some kind of unstructured storage to the specification, so that a client can request that an arbirary block of data be stored on the server under a particular key. The reason for this was given as the need to save search parameters. There was a general discussion as to the advisability of storage of unstructured data, but general, if tepid, agreement on the need to store searches. Presumably this will be debated more when the change proposal is published.

Pete agreed to submit written change proposals for formal consideration.

5. RETS 2.0 Discussions
The purpose of the RETS 2.0 discussion was to give some direction to the document editors on drafting a RETS 2.0 standard. The discussion began with a demonstration of a web-services implementation of RETS presented by Steve Verba of Avantia. He stated that the code for the demonstration project will be made available in open-source form. [The code will be posted on the developer page on the RETS site.

Steve noted that the code included a web-services front-end to a standard RETS 1.0 server, and that this would be a way to create a web-services version of RETS very quickly.

The first issue discussed was whether to switch to SOAP as the transport layer. This was generally agreed, although Stuart Schuessler stated that he believed that the change should be made earlier.

DTD extension -- serious DTD extension -- should be another goal for RETS 2.0. Switch to XML Schema was mooted but rejected for the time being, since we don't have a firm enough grasp on the data dictionary to put together a meaningful schema. Switching to schema should remain a goal.

Several members noted thast the current edit rule scheme for upload isn't sufficient for final validation, and suggested that a more sophisticated rule scheme be included in RETS 2.0.

Expansion of functionality is also a major goal. The objective should be to permit RETS servers to interoperate easily with other web-services based standards. There should also be additional functionality for ordinary agent functions. The extent to which this requires transaction changes is unclear.

Finally, as indicated suggested above, RETS 2.0 should offer a full web-services model. Implementation of this should be optional, not required.

6. Next Meeting, Other Adminstrative Details
The next meeting will be in December, with the preferred location being Phoenix. Several attendees suggested holding the meeting concurrently or sequentially with the NAR convention. Others demurred, saying they'd be too busy coding (before) or following up (after) and preferred a different time. The question will be voted on again next meeting. Several attendees requested that more notice be given of the date and place of the next meeting.

Attendees who had volunteered for workgroups said that a collaboration tool on the RETS web site would be useful. Suggestions were made for a Wiki page, a news server, and several other tools. This will be implemented shortly.

A number of attendees asked that the meeting materials be distributed earlier than they were, and that the draft revision be made available sooner. The agreed schedule (above) should take care of that concern.

Attendees also asked for a differences document between document versions 1.0 and 1.01. In addition, future revision should include revision marking in the drafts.