[Rets-dev] RETS 2.0 Discussions

Tue May 1 20:33:27 CDT 2007

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/20070501/e0ead878/attachment.html