RETS 2.0 Project Update
| Query Investigation |
| The Query Language Investigation reported back on March 26 (the report is available as a PDF). The general conclusion is that while DMQL2 needs improvement, it is a sufficiently robust base, particularly considering the migration issues, that it should be kept. A series of improvements were suggested in the report, including cross-resource joins, calculations and aggregate functions. Several outright deficiencies were also noted.
The contemplated additional functionality does not require a general-purpose query language, so query requirements for parts of the standard outside MLS queries will be dictated by the underlying business requirements.
Since the group's conclusion is that DMQL2+ (I suppose, DMQL2++) is to continue to serve at least for MLS query functions, an omnibus change proposal should be put forth to add the improvements to the 1.x track, at least for those changes which are backward-compatible.
Other languages or query facilities examined were XPath, XQuery, XQL, OQL and SQL. |
| Transport |
| The transport investigation reported that there were really two viable alternatives: RETS 1.x and SOAP. The group decided to standardize on SOAP, pending any good reason to do otherwise. In the six weeks since that decision, none has been forthcoming. The group needs to flesh out what this means.
It was decided that the problem of large bulk transfers could be addressed by keeping the RETS 1.x transport specifically for large MLS transactions. which may not be served well by existing SOAP toolkit implemenatations, or which may require data transmitted outside of the SOAP envelope, complicating implementations. There was no concensus on whether this should be the only way of querying MLS data in 2.x. The two arguments concerned the requirement to implement two different transports for a 2.x RETS implementation, opposed by the ease-of-implementation issues for clients using SOAP. This remains to be decided. |
| Data |
| The data investigation started with the Real Estate Object Model developed by Avantia. In addition, the group chose to look at offer management as a chunk that is small enough to attack with a volunteer group, yet also useful to the community. Paula O'Brien of Avantia guided the group through that portion of the object model in a conference call on May 26. Further conversations with Avantia strongly suggest that we pull in current transaction system vendors, and use the RETS process to help them define the data in the transaction standard.
Another charter for the data workgroup is to determine whether RETS should move to schema from DTD. This is still an action item. |
| Security |
| RETS 1.x does not address security except in the most rudimentary way, and this is one of the key facilities to be provided by RETS 2.0. It is desirable that the 2.0 work be submitted to 1.x wherever compatibility can be maintained.
In terms of a security architecture, the group selected the OASIS WS-Security specification. This works best in a Web Services architecture, which is assumed for RETS 2.0. The group must still prepare a roles and permissions model, and must define a mechanism for adding both end-to-end and store-and-forward security to the RETS 1.x architecture. The group also favors the adoption of RFC 3514 as part of RETS 2.0.
Task list for next phase
- Prepare formal specification of enhancements for DMQL2.
- Finalize the recommendation for large MLS transactions.
- Decide on whether to base RETS 2.0 on schema.
- Model roles and permissions for RETS 2.0 security.
- Define a security model for COMPACT-format data.
|
|
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|