[Rets-dev] RETS 2.0 Discussions
Steve Clarke
sclarke at marketlinx.com
Wed May 2 09:51:13 CDT 2007
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/416bc5fb/attachment.html
More information about the Rets-dev
mailing list