[Rets-dev] RETS 2.0 Discussions
Stuart Schuessler
sschuessler at tds.net
Wed May 2 10:05:41 CDT 2007
That is well reasoned. We voted to form a committee to resolve the problems
in RETS 1.x. There have been a number of items that seemed to have been
left out or not fully explained after reading the history of meeting notes.
Honestly I am not sure what to do. That is why I was trying to gauge the
idea of MLS System Standard and Transaction Management Standard. There
really has already been a great deal of work on both, but if RETS 2.0 is
going to ignore the previous work of 1.x then it is truly a separate
standard written for a different business need. We have gotten ourselves in
a mess because there is not a clear upgrade path. There is throw away RETS
1.x and do RETS 2.0. I am not sure that is a reasonable path for those
actually paying the bill.
I honestly believe that if we had gone with the original idea of building
out RETS 1.x using change proposals we would have been further along on RETS
2.0 by now. But like you said: Here we are. If we do not want two
standards then we need to figure out a migration path. There needs to be a
business need to move in the RETS 2.0 direction and currently there does not
seem to be one.
The committee that was formed is only reporting what needs to be changed in
RETS 1.x. We will not actually be making the changes so at least most of
what is wrong will be known by the RETS Group. It is up to the RETS group
to make the changes.
Stuart
_____
From: Steve Clarke [mailto:sclarke at marketlinx.com]
Sent: Wednesday, May 02, 2007 10:51 AM
To: Stuart Schuessler; Sergio Del Rio; RetsDev
Subject: RE: [Rets-dev] RETS 2.0 Discussions
My recollection was that originally the plan for RETS 2.0 was to "just put a
SOAP wrapper" around 1.x, essentially keeping the metadata structure the
same, the query language the same, etc. That's obviously not what happened.
In my opinion, we put a lot more effort into 2.0 than what was really needed
to get to this point. Nonetheless, we are where we are. I was really OK
with this until doubt was raised by the independent survey results at the
Austin meeting. Given that I cannot change the past (even though I
certainly tried), I can only try to influence the future. I believe that if
we now go back and "repair" 1.x in order to remove ambiguities, correct
known issues and to improve adoptability, then we really have a dilemma.
How can we justify going back and repairing 1.x when we know we will be
making a "hard left turn" with 2.0 in the immediate future. In my opinion,
if we actually do decide to re-work 1.x then that also implies that 2.0 will
need to be brought in line with the revised 1.x specification. In essence,
2.0 should really just be the SOAP wrapper around the "fixed" 1.x.
Alternatively, if the current 2.0 approach is to prevail, then I believe we
SHOULD NOT go back and fix 1.x, but rather spend our time fixing 2.0 and
accelerating its adoption.
That's my opinion.
smc
_____
From: rets-dev-bounces at rets.org [mailto:rets-dev-bounces at rets.org] On Behalf
Of Stuart Schuessler
Sent: Wednesday, May 02, 2007 7:21 AM
To: 'Sergio Del Rio'; 'RetsDev'
Subject: RE: [Rets-dev] RETS 2.0 Discussions
It would be great to hear from someone else. I know exactly what your
opinion is.
_____
From: rets-dev-bounces at rets.org [mailto:rets-dev-bounces at rets.org] On Behalf
Of Sergio Del Rio
Sent: Wednesday, May 02, 2007 2:17 AM
To: 'RetsDev'
Subject: RE: [Rets-dev] RETS 2.0 Discussions
I hardly think that my e-mail constitutes jumping down anyone's throat. I am
merely trying to state my points about the merits of RETS 2. I happen to
think that having two standards out there will confuse things further and
reduce the adoption of RETS. I fail to see how RETS 2 with it's metadata and
COMPACT format is not just as valid a method of getting data from MLS
systems as RETS 1.7.
Regards,
Sergio Del Rio
Templates 4 Business Inc.
From: Stuart Schuessler [mailto:sschuessler at tds.net]
Sent: May 1, 2007 8:23 PM
To: 'Sergio Del Rio'; 'RetsDev'
Subject: RE: [Rets-dev] RETS 2.0 Discussions
I was at the meetings for RETS 2.0 so I am not sure what you are talking
about.
I voted to move SOAP forward. I wanted to put a SOAP interface on RETS 1.x.
We were planning to do that. FORMAT= was going to be the payload and there
was to be a new metadata.
I am not suggesting that the specification be thrown away. I am suggesting
that RETS 2.0 be a transaction management specification.
>> I say let's work through the Payload issues and see if we can make this
work. There is likely a solution out there that will work for everyone.
OK, Let's see, but the idea of making RETS 2.0 a transaction management
standard and RETS 1.x a MLS System standard is a valid point if we are
unable to come up with a solution otherwise. There does not seem to be a
great deal of interest though.
I am not anti RETS 2.0. I would have liked to see it further along. I am
concerned that a lot of history and business use cases have been ignored and
will have to be put back into the specification. I am concerned that there
is not more participation in writing the architecture, that basically it is
left to a select few.
I am most of all concerned that anytime someone has a dissenting view of the
world there are no less than 4 consultants that jump down their throat. It
is the same 4 that respond every time. Why is that?
_____
From: Sergio Del Rio [mailto:Sergio.Del.Rio at t4bi.com]
Sent: Tuesday, May 01, 2007 9:33 PM
To: 'Stuart Schuessler'; 'RetsDev'
Subject: RE: [Rets-dev] RETS 2.0 Discussions
Stuart, you have to realize the we moved on after you stopped coming to the
RETS meetings. We made progress, we made changes, we had many, many
conference calls where RETS 2.0 was discussed, we had many meetings where
RETS 2.0 was discussed in detail, we reviewed and re-reviewed the RETS 2.0
Specification until we were all happy with it. Yes, we even realized that
removing COMPACT out of 2.0 was, in fact, a mistake for reasons which I
believe are obvious based on discussions so far today.
The RETS 2.0 Specification was voted in as the correct direction for reasons
already stated several times.
You were even quoted as being in favour of SOAP and wanting to adopt it
sooner, rather than later. Well, Web Services use SOAP as the underlying
protocol.
The other quotes you have are so old that we were all, everyone in the room
in 2002, very cautious that actually trying to move to a 2.0 Web Services
and SOAP transport that long ago was probably not a good idea. The tookits
back then were practically non-existent never mind providing for
interoperability between .Net and Java. In later meetings we opened the
doors to potential options.
Now, we are at the point where we have a full specification. Granted we
probably need to discuss Security a bit more and there is the issue of the
Payload documents. And there is also the issue of making Update work as we
all want it to. But the specification works and Update is not much worse off
than it was in the original specification really. As you are aware, we are
working hard to resolve all of these issues.
The RETS 2.0 specification, if you take a look at the most recent document,
is a complete and workable solution. Other than Update, it has everything
that we need to use Web Services and get the same results we used to get but
it can be done with XML or with COMPACT in a valid and predictable way.
I think the specification has made great progress and should not be simply
thrown away because people can't agree on whether or not to put strong
typing into the payloads.
I say let's work through the Payload issues and see if we can make this
work. There is likely a solution out there that will work for everyone.
Regards,
Sergio Del Rio
Templates 4 Business Inc.
From: Stuart Schuessler [mailto:sschuessler at tds.net]
Sent: May 1, 2007 6:17 PM
To: 'Sergio Del Rio'; 'RetsDev'
Subject: RE: [Rets-dev] RETS 2.0 Discussions
I have been reading a lot of the history trying to make sure everything that
was agreed upon is in the specification- at least it is presented to the
RETS Group as a whole if it is missing.
RETS 2.0 has been in development since it's inception on June 2002. We are
approaching our 5th anniversary.
That is actually one of the first references. I found where we had agreed
to pursue RETS 2.0 as a gradual migration from RETS 1.x. A year later Bruce
showed the same presentation and the group then decided to pursue RETS 2.0.
It is odd that the group changed directions like that. I remembering being
against it but for some reason it was pushed through. This is also the
meeting that Bruce introduced the 2 implementation rule that I was against.
This is the meeting that effectively ended progress in RETS and set us up
for where we are today. Reading the meeting notes for 12/2002 the
prediction presented there is basically coming true. I would say that the
December 2003 meeting marked the end of any progress in RETS. Since then
there have been endless committees not really accomplishing much.
I found this statement interesting: A vote was taken on a motion to
eliminate COMPACT in 2.0. The motion passed with 26 in favor and 2 opposed.
REF: http://notes.rets.org/retsorg.nsf/pages/meetingnotes20040803-05
Did we ever vote to add Compact back in to the 2.0 standard?
The document you are referencing is the first indication we would be
pursuing RETS 2.0
http://notes.rets.org/retsorg.nsf/pages/meetingnotes122002
"Surprisingly (to Bruce, anyway), there was overwhelming, though not
unanimous, sentiment for not starting on a specific RETS 2.0 proposal.
Though the RETS group would eventually release a 2.0, we should reach that
goal by incremental change using the existing change proposal mechanism. The
concern was that some developers, knowing that a 2.0 was coming and that it
might be substantially different, would delay development work until 2.0 was
published. The fact that the 2.0 process would be open and that interim
drafts would be public was not considered adequate to overcome this concern.
"
http://notes.rets.org/retsorg.nsf/pages/meetingnotes20031209-10
Bruce Toback began the discussion of RETS 2.0 directions by giving exactly
the same presentation he gave exactly one year earlier. The reaction this
time, however, was considerably more favorable.
The group approved the formation of a workgroup to create a 2.0
specification using the guidelines outlined in the presentation. The
timetable was:
April, 2004
Workgroup presents architectural overview and requirements document to RETS
Working Group for comment
August, 2004
Preliminary draft of RETS 2.0 document presented for comment
December, 2004
Final draft of 2.0 document, including reference implementation
RETS 2.0 would become the current version one year later, in December, 2005.
There will be a 1.8 document in parallel with the 2.0 document, which will
be focused on fixing interoperability problems rather than adding new
features. New features will be placed on the 2.0 track.
RETS 2.0 is expected to be SOAP-based. It was recognized that there are
architectural issues with SOAP in a high-volume data transfer environment,
and one of the principal challenges for the April engineering requirements
draft will be a solution to that limitation.
_____
From: rets-dev-bounces at rets.org [mailto:rets-dev-bounces at rets.org] On Behalf
Of Sergio Del Rio
Sent: Tuesday, May 01, 2007 7:16 PM
To: RetsDev
Subject: [Rets-dev] RETS 2.0 Discussions
Stuart, you asked if we had any documentation about the RETS 2.0 direction
statements from previous meetings and it turns out we do, I stand corrected:
http://www.rets.org/cms/meeting/june-2002/meeting-notes
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.
Regards,
Sergio Del Rio
Templates 4 Business Inc.
Phone: (604) 529-1544
Cell: (604) 788-3604
Fax: (604) 676-2562
Web: http://www.t4bi.com <http://www.t4bi.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rets.org/pipermail/rets-dev/attachments/20070502/cdf1d52c/attachment-0001.html
More information about the Rets-dev
mailing list