The interoperability forum came up with a number of issues. Some are with the specification, and others are with various implementations that are problematic under some circumstances:

• Not all servers react the same way to invalid names in the Select parameter. One implementation ignores the invalid columns, while others return a RETS error. It was decided that returning the RETS error was the correct behavior (though the other could be justified).
• One server implementation includes a <!DOCTYPE> declaration in its XML documents, causing problems for several clients that try to validate the returned XML if a DTD is available. Since the doctype is a SYSTEM DTD, this obviously won't work. The server implementer will remove the doctype declaration from the documents, since it's optional in any case.
• Using a fully-qualified domain name in capability URLs may cause problems when connecting initially with an IP address rather than a domain name. (This was necessitated during the Plugfest by intermittent DNS service.) When the server returns capability URLs with an FQDN, this overrides the use of the IP address. In general, this shouldn't be a problem if DNS is functioning. (Lack of DNS also hampered interoperability by causing cookies domains not to match.)
• It was noted that the Reference Implementation allows malformed queries. A short discussion followed on how resources should be labeled: a reference implemetation should follow the specification's general guideline to be lenient in what it accepts and strict in what it sends. The compliance checker is the right tool for someone who needs strict interpretation of what is accepted.

Demonstrations/show-and-tell  There were three entrants in the show-and-tell for this year. Mark Scheel's demonstration project, entitled "Mother-in-law Calculator", took the Best Demonstration prize, a 20GB Apple iPod.

Paul Brockmeyer	Aubrey Jackson	Kerry Tarr
Andy Furman	Joe McChristian	John Tull
George Green	John Rayburn	Steve Verba
John Ho	Paul Stusiak	Scott Woodard

1. OSCRE (Andy Furman) is attempting to come up to speed on how RETS was constructed, the data dictionary and experiences with the implementation of the standard.
2. Purpose is to investigate if there is some common ground between their standards efforts and the RETS standard efforts or some cross-fertilization between the groups.
3. OSCRE is basing their work around UNC/OASIS
4. The observation was made that there is greater standards adoption outside of the US. As well, because of the greater involvement of the government in the property market can make the implementation of such standards simpler.
5. Fact was offered that the US government owns/leases about 25% of the commercial space.
6. NAR is already working with the Commercial Information Exchanges (CIE)
7. NAR is looking for interoperability between the CIEs
8. CIE work is similar to the RosettaNet idea, starting small with a core of standard names (70 or so names)
9. OSCRE is looking at ebXML rather than a simpler transport
10. A comment was made that ebXML is web services on steroids.
11. The observation was made that the current RETS has a significant adoption because it is not complex and the skill level of the implements varies greatly.
12. RETS can use a custom DTD to add other data dictionaries like that discussed in OSCRE.
13. A comment was made that there has been some work done on mapping the commercial information to RETS but it is not in the standard yet.

Action Items
1. Set up a teleconference between the OSCRE technical task and some RETS members. (Andy, Steve?)
2. Discover what the status of the commercial mapping is in RETS (Paul).

Recognition Mechanisms for RETS Compliance  The first concern expressed with regard to implementing functional area compliance concerned emerging complexity in the recognition mechanism as a consequence of the growing components of what Compliance means.

Apparent components include:
1. Base
2. RETS version
3. Update
4. Functional Areas

One participant expressed the concern that recognition was necessary for the version of the compliance checker as well, since later versions of the compliance checker represent stricter adherence to the standard. However, it was noted that anyone who actually signs the license agreement has agreed to improve their products, if necessary, to continue to pass the compliance checks.

Jennifer Cleverley noted that when she goes to buy a WiFi product, she just looks on the back of the package to find the support grid. It was suggested that we investigate how the WiFi Alliance approaches the issue of having only one logo supported by a more detailed list of components implied by the particular vendor using the logo. Keith Garner, having access to the Internet in the meeting, did a preliminary check and found that WiFi has separate graphics associated with their main logo in order to differentiate between their standard versions. In the initial investigation, there did not seem to be any constraints on what the vendor is allowed to say outside the graphic. A suggestion was made that RETS could in fact constrain what licensees claimed about their product.

It was noted that the present system makes it possible for a server vendor to have coompliant software, yet nowhere have a compliance installation. The suggestion was made that the highest recognition be reserved for vendors who have actually implemented their RETS-compliant solution at their customer sites. Perhaps the i mplementation issue can be best recognized by awarding RETS-compliant recognition to MLSs.

Performance Component of Compliance  The suggestion was made that compliance should include a maximum allowable elapsed time to conclude each compliance test. The groups actually performing the compliance checks will report back if the absence of a maximum allowable elapsed time is a problem.

Maggie Diaz indicated that WyldFyre experiences considerable variety of elapsed times from one RETS vendor to another. For now, the group agreed to set the maximum allowable elapsed time at 5 minutes for operational purposes only; not as a compliance criterion.

Update on Compliance Checkers

Server Compliance Checker  Steve Verba of Avantia has submitted a proposal to NAR to:
1. Make compliance checking self-serve through the Web.
2. Raise the testing bar of the Server Compliance Checker.
3. Improve the Avantia reference implementation.

Client Compliance Checker  Steve Verba of Avantia has submitted a proposal to NAR to:

• Port the Client Compliance Checker to operate visually the same as the Server Compliance Checker.
• Make compliance checking self-serve through the Web.
• Raise the testing bar of the Client Compliance Checker.

Thanks to Yogi Schulz for help in scribing this workgroup session.

Leo Bijnagte	Jim Dodd	Joe McChristian III	Sanjay Tiwani
Laure Chipman	Dave Dribin	Shawn Meissner	Dan Woolley
Steve Clarke	Jaison Freed	Dan Moore	Joshua Vosper
Jennifer Cleverley	Keith Garner	Kirk Piegols	Brian Young
Sameer Danthurthy	David Harris	Brian Rook	Wantao Zhou
Sergio Del Rio	Max Kondratyev	Yogi Schulz
Maggie Diaz	Alex Makhanko	Marc Smolenski

The Data Dictionary workgroup ran unusually long this week in order to complete the review for at least one Functional Area Compliance project (see the December 2003 meeting notes for the initial reference to Functional Area Compliance).

Additional StandardName entries  The first item on the agenda was to add StandardName entries in the RETS data dictionary for elements which were missing them. The names were reviewed and the list was accepted with some minor corrections. The list submitted to the workgroup can be found in the meeting package.

Functional area compliance  The next item on the agenda concerned functional area compliance. Although several people volunteered to do two functional areas at the December meeting, this was not followed up. The group agreed to try to hammer out at least the data dictionary entries for CMA compliance at this meeting. The dictionary document was examined line by line and candidates for inclusion were annotated.

During the annotation process, it was determined that the original categorization of "required" was insufficient: the group identified a number of items that should be on a CMA but might not exist in a data base. A second category of "Must be mapped if exists" was created to handle these. In addition, the group briefly discussed adding requirements for making certain of these items searchable as part of a functional area specification. Bruce Toback agreed to pull together the annotated fields and propose items that should be required to be searchable. This list will be reviewed on a Data Dictionary conference call.

The workgroup had a brief discussion on whether a vendor could simply write a functional area specification and require compliance with it. While the general sentiment was against this, it was pointed out that the HomeStore functional area does indeed represent a single vendor. The solution was to change the name of the are to Data Aggregation. Jennifer Cleverley of HomeStore will nonetheless be taking the first cut at writing the functional area compliance specification for this area.

Requirements of Broker BackOffice Systems  Jennifer Cleverley of Homestore raised the question of the extent to which the requirements of broker back office systems should influence the development of RETS. This is a large topic that the group could not address at this time.

Thanks to Yogi Schulz for help in scribing this workgroup session.

Steve Byrd	Joe McChristian Jr.	Jon Tull
Jennifer Cleverly	Joe McChristian III	Tom Vanhoutte
James Ferguson	Sam Roy	Brian Young
Mark Lesswing	Yogi Schulz
Bob Laws	Madeleine Talbot

Overall RETS marketing goal The organization that will drive RETS adoption varies from market to market. The most common leading organizations are:
1. Brokerages
2. MLSs
3. MLS system vendors

Raising Awareness 

Stakeholder Name	Current level of Awareness	Potential Actions
MLS system vendors	High among large vendors	Maintain communication with large vendors Bring more vendors into the loop about compiance, site audits, 2.0
MLS IT staff	Low to non-existent	Maintain communication
MLS IT execs	High	Begin business-oriented communication
Large national brokers	Low to non-existent Keen interest in data aggregation	Create and disseminate a message about how RETS simplifies and accelerates data aggregation
Regional/local brokers	Low to non-existent	Begin business-oriented communication
Third party software vendors	Increasing	Maintain communication with in-the-loop vendors Bring more vendors into the loop
Agents and Realtors	Low to non-existent	Unlikely to be influential as individuals

RETS Survey - 2004 

Themes the group found interesting
1. Question 16: Surprising that majority of respondents did not see advantages in RETS. May reflect the immaturity of the RETS implementations.
2. Question 5: Surprising that respondents see RETS as either all on or all off.
3. Barry Diller: packaging services for brokers presentation at Inman.
4. Group delighted that survey was conducted. Saw valuable nuggets in the survey they could use/communicate individually.
5. Little increased adoption in 2004.
6. The McChristians believed they have benefited materially from having having their client product certified.
7. Reaction to new technology often increases fears that I will:

• Lose control over my business and/or data.
• Have to spend big bucks.
• Become obsolete/irrelevant.

Potential priorities for RETS marketing:
1. Sell RETS benefits
2. Discover impediments to using RETS
3. Starter kits for those interested to use RETS
4. Development of data management best practices for real estate
5. RETS is becoming a buzzword. We need to focus on increasing adoption of RETS-Compliant solutions. RETS-Compliance cannot have multiple meanings.
6. Defining and communicating the RETS value proposition more clearly.

Sound Bytes 
1. Brian Young: Adoption of RETS has reduced MLS staff workload to support data downloads to data customers. Keen to abandon FTP as soon as possible.
2. Madeleine Talbot: No longer experience nightmare of writing custom exports for every data request.
3. McChristian III: Simplifies creation and operation of broker/agent web sites. Now able to offer real time data. Big improvement over overnight data.
4. McChristian Jr.: The RETS community brought resources to us that enabled us to accelerate our product development work and opened new business opportunity doors.
5. Mark Lesswing: RETS increases the richness of software choice.
6. James Ferguson Ð RETS lowers my cost per transaction to move and manage data. RETS enables augmented services like AVMs.

Events where RETS should be more visible 
1. Council of MLS.
2. Connections.
3. Franchise meetings.
4. Flash web page that communicates the RETS message continually.
5. Create regional RETS user groups.

CTR Support for RETS Community  Mark Lesswing is prepared to provide to the marketing committee:
1. Framework for best practices for data management and how RETS contributes.
2. List/survey of products and services.

Revised RETS 2.0 schedule The initial item on the agenda was to set the schedule for introduction and mainstreaming of RETS 2.0. The initial suggestion from Bruce Toback was that a working draft of RETS 2.0 be put out in time for the March 2005 meeting and that the RETS 1.8 final period (starting in November 2005) run alongside the RETS 2.0 draft period. RETS 2.0 would then become final at November 2006.

Nearly everybody in the group thought that this proposed schedule was stretched out much too far. There was a short discussion on whether a RETS 2.0 draft could be published in time for the December meeting, including an initial implementation (as is desired for RETS 2.0). Steve Verba said that he believed his company could in fact write an implementation on that schedule provided that the initial draft could be published incrementally and starting no later than mid-September. There was also discussion of whether the RETS working group, with its limited resources, should even be publishing a RETS 1.8, which would dilute developer resources and might cause confusion in the marketplace. As the alternative, key changes for 1.8 should be incorporated in 1.7, and the November 2005 "final" draft should be version 2.0, standing alone. There was general assent to this schedule revision, and the discussion leader quickly switched to leading the group in the direction that it was obviously going to go anyway. The issue of making a late-cycle modification to RETS 1.7 is to be put before the full group on Thursday.

The group then created a short list of high-level architectural decisions that need to be made:

• Transport
• Security model
• Query language
• Metadata architecture
• COMPACT format
• Rule metadata for UPDATE
• Update architecture in general
• Expansion of the transaction set

Transport  Since the group had already decided on using SOAP in earlier conference call discussions, and since it was desired to use WS-Security to implement the security requirements of the standard, the group decided to use all of web services. There was no consensus on whether a UDDI registry was required: while it would not be of much use for the MLS part of RETS, it would certainly be of use in other parts of the transaction. The group agreed to postpone the discussion of UDDI pending further investigation and determination of the initial transaction scope.

Metadata Architecture  The initial suggestion for a RETS 2.0 metadata architecture was to use XML Schema to describe the data, and this sentiment persisted throughout the discussion. Several participants pointed out that schema by itself is insufficient to provide all of the metadata now present in RETS -- the update metadata was mentioned particurly. The group discussed the suggestion that there be multiple metadata types, as now, with transactions to retrieve the additional parallel metadata. There was brief discussion of incorporating some of the additional metadata into the schema document itself, but several members pointed out that there may be no way to get to this "embedded" metadata using standard tools so the discussion point was not followed up.

The issue of retaining tool support was also discussed with respect to lookups: lookups need to be accessible to rich clients in order to construct a user interface. However, if lookups are moved out of the schema, then schema loses its value for validation. So it looks like there might have to be redundant specification of lookups in order to fulfill both requirements.

A motion to use schema for metadata representations passed 20-0.

COMPACT Retention  There was a lively discussion on whether or not to keep COMPACT. The arguments against keeping the included:
1. Double-escaping requirement
2. No possibility of structure information
3. Securing individual fields, a key goal of RETS 2.x, would require inventing an entirely new security apparatus
4. No standard tools to handle COMPACT
5. Requires that server vendors maintain two different methods to do the same thing

The primary arguments in favor of keeping it included simplicity and particularly, performance. It was pointed out that perhaps the performance issue was really a symptom of another issue: either improper pricing, meaning that users downloaded large fractions of a data base simply because it was easy to do; or lack of any other way of effectively maintaining a distributed data base. Part of the group thought that if these two problems were fixed, then performance on large downloads wouldn't be an issue because there would be fewer of them. This was disputed by the other part of the group, and no consensus developed on the issue.

Binary XML was suggested as one solution to the performance problem, and Steve Verba noted that there was already an implementation of WBXML in the Sandbox. The group agreed that we should look at the updated Binary XML standard to see if it could meet the needs for better performance.

A vote was taken on a motion to elminate COMPACT in 2.0. The motion passed with 26 in favor and 2 opposed.

Query Language  The group briefly reviewed the information produced by the group investigating query languages. The short summary was that of the languages reviewed, three seem to meet some of the criteria: an SQL dialect, the W3C standard Xquery and a revision to DMQL2, to which the group gave a working name of "DMQL3". Sergio Del Rio, who coordinated the query language investigation, noted that SQL had two flaws for purposes of RETS: first, that the RETS specification would have to include many restrictions on SQL features -- in effect defining its own dialect of SQL -- so that the language's value as a "standard query language" would be considerably reduced. Second, SQL does not function well in a schema environment both because of its name syntax and because of problems mapping deep structure back to relational tables. This means that we would have to put extensions into our restricted SQL.

Xquery also received considerable attention. Initially, the main concern was the state of toolkit support, allowing Xquery queries against common data base systems. It was stated that Microsoft and Oracle were both "working on" Xquery support, but that neither had a finished product. Later in the discussion, concern was expressed that Xquery would not function well at least in an MLS environment and perhaps more generally because of the difficulty of mapping Xquery, which is partly procedural, onto a relational model.

Avantia suggested that in the absence of hard data, an experimental implementation might go a long way toward answering some of these questions, and the group agreed to defer the question of query language until after a more detailed investigation of Xquery. A motion to defer the decision until after we have hard data on Xquery and a revised DMQL was made.

Wantao Zhou of Interealty proposed a subsidiary motion to add an XML representation of DMQL to the two languages mentioned in the motion. He will provide a specification for an XML version of DMQL3 (Xdmql?) that can also be tested. The subsidiary motion passed 15-0, and the full motion passed 20-0.

Update  The discussion of update covered several issues. Some of these were resolved without dissent: there should be a schema for each update type, the business rules (other than simple type validation) should be encoded in extended documents, and that after an investigation of BPEL as an alternative for validation, we should stick with something close to the existing grammar for expressing field validation (modified, obviously, for using Xpath instead of simple names). Several of these issues were discussed in the Update workgroup session which took place earlier in the day.

There was a brief discussion of the issue of locking. It was suggested that the client be required to send the entire old and new records to the server on an update so that the server could better perform optimistic locking. There was some dissent on this point since either the server or the client might choose to make different decisions (abandon, merge, overwrite) depending on what had changed in the record. No resolution was reached.

Security  Paul Stusiak did a brief walk-through of the proposed security model, both the use case and object model. Avantia's Real Estate Object Model, available in the RETS Sandbox also addresses security in terms of roles and permissions. It was noted that the early MISMO drafts had a comprehensive party model, as does ebXML.

Heard during the discussion: "I make a call and poof-voila, you have authentication!"

There was a question as to whether the specification actually needs the ideas of roles, rather than individuals. The consensus was that roles are required for many different potential use cases. Many of the examples centered around delegation: a listing secretary who is delegated the authority to change certain things on certain listings, for example, or filling out a listing contract. There was also a question of whether the specification needed to include one-time delegation.

Leo Bijnagte also pointed out that roles are required even in read-only applications: a role defines what can be seen on a record. This is especially true in a transaction system.

Another issue in the delegation area comes up, again using the example of a listing secretary, when an individual may be delegated different roles for different people.

The concensus was that the group needs additional use cases and additional and more detailed information on roles. Paul Stusiak will generate some additional use cases, and Steve Verba will check with transaction vendors on additional well-known roles that should be included in the specification.

Session Management  There was a brief discussion on session management: is there a standard? It was noted that the Jakarta Project has links to infrastructure classes. [Ed: I have been unable to find a definitive link to use for these notes.]

Further Discussion  The group agreed to biweekly calls starting Wednesday, August 18, at 8:30 AM Pacific/11:30 AM Eastern; the first call will deal with the additional information to be presented on security. A full agenda will be posted on the RETS 2.0 workgroup page

1. Most of the meeting attendees were interested in understanding what the issues were in new implementations
2. Only a couple of the attendees had working Update Transaction solutions
3. Of the working Update Transaction vendors, there were no major issues that they brought up.
4. Some of the issues for having external update applications were related to control issues. The server vendors have traditionally had entire control over the entry of data into the system. If the Update transaction is not implemented, then third parties canÕt insert/create records. The server vendors appear to have gotten over this concern, many have provided the Update transaction
5. Update as a task is non-trivial. You need to integrate the metadata for the available business rules with the high degree of error handling that server-side validation can generate.
6. Rule support was deemed to be adequate within the current system. Additions to the update metadata can be done within the existing specification.
7. It was considered revisiting the ECMAscript proposal, but it was pointed out that the expression of business rules in Javascript can quickly become very complex.
8. Additions that might be considered are that there is no way to provide validation expressions that depend on the situation. An example is that a specific fieldÕs behavior is dependent on another field.
9. Proposed solution was to extend the metadata, adding Mandatory, Visible and Editable. At a later date, this could be converted to a change proposal.
10. Improved rule support and simple rule implementation had a lively discussion. It was tabled to a future meeting for further discussion.
11. XML support for the Update transaction was broadly supported. A change proposal was suggested. It was tabled until the next meeting, based on results from the 2.0 investigation.
12. Additional metadata and hints were deferred to the 2.0 standard.
13. An agenda item was added to discuss notification and the possibility of using RSS. RSS was dismissed as a viable notification mechanism based on participant experiences. The agenda item was intended to stimulate discussion and was successful. It was tabled for further discussion to the mail list as interest demands.
14. The remaining two agenda items were tabled because the allotted time was exceeded.
15. An additional item was added after the meeting where the dormant PutObject Transaction was revived.

The group had the following recommendations:
1. The site needs a short description of RETS somewhere where it's immediately visible.
2. The site needs headlines for news articles, as now, but with much more frequent updates (weekly or daily).
3. The home page needs distinct paths for developers, MLSs and brokers, with distinct introductions for each audience.
4. There needs to be a "business case for RETS" document.
5. The RETS community section needs to have more topics and be more prominently displayed.
6. The site needs to have ways for other people to add and maintain content.

• The plenary session opened with a recap of the work done in the workgroups the previous day (see notes above). This was followed by an update on related standards. Bruce Toback did a short presentation on current activities at MISMO (Mortgage Industry Standards Maintenance Organization), in particular their move to schema for their next (3.0) version, and their extensive investigation of specifying Web Services for transport, enveloping and security. Next, Andy Fuhrman of OSCRE (Open Standards Consortium for Real Estate) then gave an overview presentation of his organization's efforts. OSCRE was invited to join the RETS process so that the two organizations could share expertise and insure interoperability where possible. OSCRE's primary focus is commercial and multi-family real estate management and acquisition.

Sergio Del Rio followed this with a presentation outlining a suggested migration path between the RETS 1.x architecture and RETS 2.0. The translation layer would allow RETS 2.0 clients to query RETS 1.x servers transparently. There was some discussion of how this could be done given application layer considerations -- transmitting permissions information, for example, or performing meaningful metadata translations. Sergio has made the presentation slides available (pdf, ppt).

The group next dealt with the request by the RETS 2.0 Workgroup to move certain changes scheduled for RETS 1.8 ahead to RETS 1.7, and to concentrate new design efforts in RETS 2.0. It was noted that the change in emphasis could be done through the normal voting procedure: if the group wants to expend more effort on 2.0, it can simply vote to include only the most urgent change proposals for inclusion in the 1.x track. No formal vote was taken on the proposal to shift the effort to 2.x since no formal policy decision was to be taken.

The group next went through the list of change proposals slated for inclusion in 1.8, and voted for each whether to move them to 1.7. Most of these were voted on with little discussion; exceptions are noted in the table below (a "yes" vote for a proposal means that it is to be moved into 1.7):

Proposal	Yes	No	Notes
031 Update Warning Block Enhancement	25	0
032 Distributed Data Base Enhancements	23	0
033 Replace Validation Expression	0	24	The group polled the server vendors present (four vendors plus several custom systems were represented) and determined that none had started implementing this change.
034 Optional "RETS-Server" Server Response Header	27	0
035 Field Data Encoding	0	22
036 Client Software Validation	25	0
041 ChangePassword Implementation	27	0
043 Capability URL Rules	26	0
044 Cookie Handling	26	0
055 DMQL2 Clarifications	24	0	This proposal was not scheduled for 1.8, but Bruce Toback requested that it be scheduled for 1.7 in order to solve some interoperability problems, particularly with non-metadata clients.

The group then took up the current set of change proposals. Bruce Toback had requested that two change proposals, 001 (Structured Data Exchange) and 042 (Custom-XML Format Option) be reconsidered, but withdrew the request given the working group's desire to concentrate new development on 2.0.

RCP 053 Enhancements to Upload  As discussion started, it was noted that the change proposal actually specifies two alternative methods of performing an upload transaction, and expects the group to pick one. A motion was made and seconded that the proposal go back to the Update workgroup, which will produce a revised proposal by November 1, 2004. This can then be voted on in the December meeting. The motion passed 17-0. It was specifically stated that the change proposal would be for the 1.x track, but that the design work would be given to the 2.0 workgroup for parallel incorporation under the 2.0 architecture.

RCP 057 Standard Names Metadata Passed without discussion, 19-0.

Wrap-up Kevin McQueen then led a wrap-up discussion soliciting feedback on the current session. Requests for the next meeting include:

• Distribute the meeting materials 2 - 3 weeks ahead of the meeting.
• Add a breakout session, similar to the workgroup sessions, for MLSs.
• Add a session, possibly at the Plugfest, in which the available free and open-source tools are demonstrated.
• Pre-announce the participants at the plugfest to allow better preparation.
• Do a better job of publicizing the opportunity to get compliance certifications at the plugfest.
• Do a code-walkthrough as part of the technical training session on the first day (or possibly in conjunction with the plugfest.
• Add a gallery feature similar to the "plugfest demos" but with more participation.

The next meeting is tentatively scheduled for December 7-9 in Phoenix.