Recommendation to rescind the "RETS 2.0 Web Service" specification

[MattL]

In recognition that:

1. The 29 Payloads defined by this Specification are no longer considered valid or complete
2. The 200 Requirements defined by this Specification are no longer considered valid or complete
3. The RQL language defined by this Specification is no longer considered complete
4. Numerous documents referenced by this Specification were never written
5. The industry, following several rigorous internal and external reviews, has determined that further development of the RETS 1.x Specifications is best for the marketplace

I recommend that the Transport workgroup summarily propose that the "RETS2 Web Service" as finalized on August 6, 2006, be rescinded as a Standard recommendation and all of its features and definitions be considered deprecated in favor of the continued 1.x Standards.

As has always been the case, conveying that 2.x is a progressive advancement versus 1.x sends an inconsistent message to the marketplace. And, with the renewed development of the 1.x Standard line, such confusion would only further harm the effort to improve RETS as it is actually implemented.

-Matt

[kgarner]

I fully support these statements.

I don't want to do a "me too" post, but that's all I've got to add to this.

[jimmy]

I am currently using a modified version of Visual Basic from Jeff Brush as an interface to send and retreive data from a RETS server. Works fine, but I wanted to connect RETS directly to WEB directly. Given the contraint of using a windows based OS and something similar visual basic or .net products what software package(s) is best for rapid deployment?

[mmcguire]

Hi jimmy,

That's a bit off topic for this thread. You should probably post something to the general development forum.

Hope that helps,

Matthew

[mmcguire]

Back on topic...

Matt, I can't really disagree with you in principal. There are clearly serious problems with the state of the 2.0 initiative. Unfortunately some of our industry partners have started using the 2.0 work fairly seriously. Given that I would like to hear their arguments as well.

I am not sure that the Transport group is the best group to discuss or even propose it. Even though the group is trying to integrate positive efforts from 2.0 (the schema work) into the 1.x realm, it would be inappropriate for the group to challenge the validity of 2.0. The Transport group subscribers don't encompass all the affected parties so I don't think it would be fair to have the discussion here.

Ideally this should be publicly discussed with the Standards Committee using some public forum that includes the most members of the community. I am not presently sure if such a forum exists. Any immediate ideas on where we can hold this discussion appropriately? I don't see an appropriate place at the moment. The current forums have broken my confidence in our community communication mechanisms.

[mwurzer]

I agree with Matt L as well, especially when it comes to compliance and certification. Whatever the service document is today, it isn't widely deployed and should play no role in certification or scorecards or anything of the sort. As to the best Forum, I would agree that the Standards Committee can and should address the issue.

[gaccawi]

There are systems out there using RETS 2.0 right now.

This forum isn't the appropriate place for this discussion. Unless the purpose was to stir things up, generate more discussion, etc. rather than actually rescind a voted in standard.

G

[MattL]

Originally Posted by gaccawi

There are systems out there using RETS 2.0 right now.

Regardless of any in-place "implementations" (which I still find difficult to accept, given that Schema is still in development and has not been voted-in, and there are more documents alluded to in the Specification, such as the Security Document, that don't exist), we as a standards body must consider what is best for the industry and marketplace. This is equivalent to practices and methodology employed by the IETF and W3C, in which staleness or incompleteness are deemed valid reasons for rescinding recommendations.

Originally Posted by gaccawi

This forum isn't the appropriate place for this discussion. Unless the purpose was to stir things up, generate more discussion, etc. rather than actually rescind a voted in standard.

I wasn't aware that you're in charge of determining the appropriate forums for discussion.
Per the governance process, recommendations for the Standards are to come up from the Workgroups to be approved by the Standards Committee & Board. Given that this is the Transport Workgroup, it is the appropriate forum in which to discuss the rescindment of an existing transport standard.

-Matt

[mmcguire]

Whoa now, let’s take it easy.

Given that the group is named ‘Transport’, we have publicly noted this is a bit of a misnomer. That isn’t to say that I disagree with your point of view, it is just that the local subscribers to this forum don’t cover all of the affected people. This is good reason to discuss this in a public fashion with the Standards Committee, who are the arbiters of such matters. Let’s work on getting this in front of the right audience and go from there. Mike seems to agree with this and he should be able to help us get this discussed openly.

Mike, there is no public forum for the Standard Committee. However I think this is a big enough issue to discuss publicly and should at the very least be presented to the general community. Do you think it would be effective to use the –dev forum or should we invite people to discuss the issue using the –announce mail list? I think people should be given time to consider the situation and propose their ideas before any decisions are made. Any change like this really needs wide consensus.

Thanks,

Matthew

[MattL]

Misnomer or not, the Workgroups are intended to be the progenitors of change recommendations. While I understand and respect your position, the point is that it is an issue that should not be brought to the Standards Committee unless and until it is recommended by a Workgroup: That is the governance model as documented today.

The intent of my original posting and the apropos of this forum is to facilitate the recommendation from the Workgroup, at which point the Standards Committee gets their say. Even then, the Standards Committee is a closed group and, if there is a vote in the affirmative, their recommendation is submitted to the Board. At that point (and only that point), the Board can choose to vote it in, solicit broad opinion, reject it entirely, etc., as they see fit.

-Matt