Re: [OSGeo-Discuss] The OSGeo response to the proposed GeoServices REST API document [was: Would you be concerned ...]
On 5/10/13 12:25 AM, Miles Fidelman wrote: Adrian Custer wrote: On 5/9/13 2:33 PM, Tim Bowden wrote: On Thu, 2013-05-09 at 13:20 -0300, Adrian Custer wrote: Hey Cameron, all, ... * The letter is only rejection of the proposal without offering an alternative way forwards. I strongly suspect the proposed standard would have received a much better reception from the broader OSGeo community (with the diverse viewpoints it typically has) if the proposal was more that a take it or leave it (partial?) description of what ESRI has done and is going to do anyway. Out of curiosity, how does this compare to the process by which KML became an OGC standard? That was the first really contentious issue I experienced at the OGC. It is related to the current situation in that the KML experience seems to have encouraged ERSI to try to push GeoServices through. However, I did not much care at the time so I did not follow the issues and controversy. I gather there was a feeling that KML duplicated other standards at the OGC and mixed data with presentation in a poorly structured way. I also vaguely remember that there was more of a feeling that Google really wanted to hand off the standard to the OGC. But again, I am not sure about any of this; I have never even seen a KML document. ~adrian This is a good example of the limits of governance at the OGC. Really, a standard should not pass when there is concerted opposition to it. The process is designed to suspend when there is opposition (2 no votes), in an effort to build consensus. However, the ultimate decision is still a 50% + 1 vote; probably, it should be a super-majority of some kind. I've always found the OGC process to be rather broken. But then I'm a big fan of the IETF approach - bottom up, rough consensus and running code, a progression from experimental to recommended to mandatory, but only after a long incubation period - and don't even think of using the word standard until there are at least 2 interoperable implementations. Miles Fidelman ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] The OSGeo response to the proposed GeoServices REST API document [was: Would you be concerned ...]
On 10 May 2013 18:40, Adrian Custer acus...@gmail.com wrote: On 5/10/13 12:25 AM, Miles Fidelman wrote: Adrian Custer wrote: On 5/9/13 2:33 PM, Tim Bowden wrote: On Thu, 2013-05-09 at 13:20 -0300, Adrian Custer wrote: Hey Cameron, all, ... * The letter is only rejection of the proposal without offering an alternative way forwards. I strongly suspect the proposed standard would have received a much better reception from the broader OSGeo community (with the diverse viewpoints it typically has) if the proposal was more that a take it or leave it (partial?) description of what ESRI has done and is going to do anyway. Out of curiosity, how does this compare to the process by which KML became an OGC standard? That was the first really contentious issue I experienced at the OGC. It is related to the current situation in that the KML experience seems to have encouraged ERSI to try to push GeoServices through. Indeed. The whole discussion is more like a cry over spilled milk. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] The OSGeo response to the proposed GeoServices REST API document [was: Would you be concerned ...]
While KML ESRI Restful are two cases of OGC potentially ratifying a non-OGC developed standard, and the situations worth comparing, I think there are two important differences. At least as I understand the situation. 1. KML was already open, widely used supported by multiple applications/vendors, so was a genuine industry standard, with a published open API before it got to OGC. 2. As Adrian mentions, control of the KML standard did not remain with Google, but was vested in the OGC. Neither point applies in the ESRI case. The Restful standard is not open, only one vendor supports it, so ratification does not immediately benefit the industry, just the one vendor effectively being given a strategic advantage. Control is not vested in the OGC, but for compatability reasons will remain with ESRI, again conferring a strategic advantage to a single vendor. This is not the role of the OGC in the spatial industry, and these implications need to be taken into account in any consideration of Open Standards. For example, WMS 1.3 was not backwards compatible with v1.0, SOS v1 2 ditto, ... the OGC did not have to seek any individual vendor's approval to modify the OGC standard. If ESRI published the proposed Restful standard as an open standard, and after genuine industry uptake, it was ratified by the OGC, with control vested in the OGC, I would not have a problem with it. Has the OGC ever previously ratified a standard it does not then control? Who decides on ERestful v1.1, etc., OGC or ESRI? If OGC cannot overule ESRI, then this should not be an OGC standard. If I'm mistaken, and the restful standard is currently widely used by non-ESRI applications, and when ratified under the current proposal it will become an OGC controlled rather than ESRI controlled standard, please correct me!! Brent Wood --- On Sat, 5/11/13, Adrian Custer acus...@gmail.com wrote: From: Adrian Custer acus...@gmail.com Subject: Re: [OSGeo-Discuss] The OSGeo response to the proposed GeoServices REST API document [was: Would you be concerned ...] To: Miles Fidelman mfidel...@meetinghouse.net, OSGeo Discuss List discuss@lists.osgeo.org Date: Saturday, May 11, 2013, 5:40 AM On 5/10/13 12:25 AM, Miles Fidelman wrote: Adrian Custer wrote: On 5/9/13 2:33 PM, Tim Bowden wrote: On Thu, 2013-05-09 at 13:20 -0300, Adrian Custer wrote: Hey Cameron, all, ... * The letter is only rejection of the proposal without offering an alternative way forwards. I strongly suspect the proposed standard would have received a much better reception from the broader OSGeo community (with the diverse viewpoints it typically has) if the proposal was more that a take it or leave it (partial?) description of what ESRI has done and is going to do anyway. Out of curiosity, how does this compare to the process by which KML became an OGC standard? That was the first really contentious issue I experienced at the OGC. It is related to the current situation in that the KML experience seems to have encouraged ERSI to try to push GeoServices through. However, I did not much care at the time so I did not follow the issues and controversy. I gather there was a feeling that KML duplicated other standards at the OGC and mixed data with presentation in a poorly structured way. I also vaguely remember that there was more of a feeling that Google really wanted to hand off the standard to the OGC. But again, I am not sure about any of this; I have never even seen a KML document. ~adrian This is a good example of the limits of governance at the OGC. Really, a standard should not pass when there is concerted opposition to it. The process is designed to suspend when there is opposition (2 no votes), in an effort to build consensus. However, the ultimate decision is still a 50% + 1 vote; probably, it should be a super-majority of some kind. I've always found the OGC process to be rather broken. But then I'm a big fan of the IETF approach - bottom up, rough consensus and running code, a progression from experimental to recommended to mandatory, but only after a long incubation period - and don't even think of using the word standard until there are at least 2 interoperable implementations. Miles Fidelman ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
[OSGeo-Discuss] The OSGeo response to the proposed GeoServices REST API document [was: Would you be concerned ...]
Hey Cameron, all, Cameron, you recently asked me to join your letter from the OSGeo to the OGC Members regarding the adoption of the proposed ESRI GeoServices REST API as an OGC standard. http://wiki.osgeo.org/wiki/Geoservices_REST_API#Open_Letter_to_OGC_and_voting_members Thanks. Your request has forced me to define my position, which has been a huge waste of my time, but was probably worth doing. My response has two sides, my position on the debate and my decision to participate in the letter. The first is my position on the actual proposed standard. The pros: * The OGC should be in the business of developing good standards, not of choosing which standards should be implemented. * The proposers of the document want to make a standard and have followed all the rules of the consortium. The work of any such group of members deserves serious, good faith consideration. * The need for an integrated suite of services using simple data, which is addressed (partially) by the document, is real. The proposed document is pushing the OGC on this issue. * The proposed document could be useful to a number of people. * The proposed document is not significantly more broken than the existing standards of the OGC. As an author of standards at the OGC, I know how totally impossible it is to write a good standard, so the weaknesses in the existing document seem more acceptable. The cons: - * The OGC is, de-facto, in the position of recommending the interoperable standards for geospatial services. The proposed document is not good enough, not widely enough implemented, and not publicly supported enough, to be considered at the same level as existing standards. * Adopting a standard implies a desire to maintain the standard but the desire to support this approach by the OGC membership is limited. The lack of collaboration on this version bodes ill for the future. * The overlap in functionality between the proposed services and the existing services, notably with the ongoing work to modularize the existing services, is almost 100 percent. However, compatibility is low. * There is already a published document: http://www.esri.com/library/whitepapers/pdfs/geoservices-rest-spec.pdf so there is no need for the document to be adopted as an OGC Standard merely for interoperability with the ESRI implemetation. * The document, as a new, separate effort, repeats mistakes which were made and since solved by the other services. * The document focuses on the past (notably with backwards compatibility and use of only GET/POST) not on the future. * The document needs a comprehensive editorial rewrite. (see at end) The problem for me, is that both simple answers are bad. A simple acceptance of the standard would introduce a new set of 'OGC approved' open services. The OGC approval might enable governments to buy a -new-name-here- solution instead of a W*S or a S*S solution. (On that, I am inclined to let them make their own mistakes.) The path forwards towards harmonizing the services is unclear. There is little good will towards the standard on behalf of the membership. Fixing this document in addition to fixing the W*S services will be a pain. Simply rejecting the solution would be bad for the OGC. It would place the OGC in the position of picking winners and losers in the standards business. It would mean that the OGC is stuck on the project of fixing the W*S standards to meet some nebulous future functionality without having any path to get there. It would discourage innovation and progress. Is there a third way? Well, actually, there is. The natural consequence of either decision is a renewed commitment towards trying to build this thing that we want, an integrated suite of simple services built using simple, well defined resources, accessible and usable using the core HTTP verbs, and discoverable through link following. That's the way forwards and why I have wasted a chunk of my life on WMS-Next. My personal conclusion, then, is that the vote does not concern me. I suspect the vote is mostly of interest to the commercial entities, groups whose self-interest is so destructive everywhere because it does not place user freedom and action first and foremost. Acceptance will have several net negative impacts on me but that's life, eh? For me, the path forwards is clear: make WMS-Next kick ass. The vote is merely a waste of my time. The second side to my response regards the actual letter. The pros: * The letter comes from the Free Software community which I think could have a voice on the matter. * The letter was started by someone who has my respect. * The letter re-enforces the link between OSGeo and the OGC. * The letter expresses many concerns which I share. The cons: * The letter
Re: [OSGeo-Discuss] The OSGeo response to the proposed GeoServices REST API document [was: Would you be concerned ...]
On 5/9/13 2:33 PM, Tim Bowden wrote: On Thu, 2013-05-09 at 13:20 -0300, Adrian Custer wrote: Hey Cameron, all, ... * The letter is only rejection of the proposal without offering an alternative way forwards. I strongly suspect the proposed standard would have received a much better reception from the broader OSGeo community (with the diverse viewpoints it typically has) if the proposal was more that a take it or leave it (partial?) description of what ESRI has done and is going to do anyway. Undoubtedly. This was as undiplomatic as they could have been. If there was at least some willingness to engage with the broader community on interoperability within the standard (and how do you have interoperability if you aren't willing to budge from a pre-defined position anyway?). And there would have been more participation at the OGC. Lots of folk were excited at the start but gave up when backwards compatibility was set in stone. Perhaps ESRI didn't realise their approach was going to come across with an up you attitude (or maybe they did)? The impression I've got it that many people feel ESRI is treating the OGC as a rubber stamp body (which very much implies arrogant contempt) regardless of the merits of the proposal. Much more likely, ESRI is trying to push through its standard, distinct from expecting the OGC to 'rubber stamp' it. They knew from the get go they were going to face this opposition. The only question is who is stronger. This is a good example of the limits of governance at the OGC. Really, a standard should not pass when there is concerted opposition to it. The process is designed to suspend when there is opposition (2 no votes), in an effort to build consensus. However, the ultimate decision is still a 50% + 1 vote; probably, it should be a super-majority of some kind. Hopefully I've got it wrong and ESRI really just botched their approach on this one (why do I feel this is naive wishful thinking?). FWIW, I don't believe having an alternate incompatible standard must of itself be a deal breaker, if the proposed standard genuinely represents a viable attempt at interoperability. After all, the wonderful thing about standards is there are so many to choose from. ;) Lets just not pretend it's about genuine interoperability unless that really is the case. I doubt anyone is that naive. Regards, Tim Bowden cheers, ~adrian ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] The OSGeo response to the proposed GeoServices REST API document [was: Would you be concerned ...]
On 05/09/2013 07:33 PM, Tim Bowden wrote: On Thu, 2013-05-09 at 13:20 -0300, Adrian Custer wrote: Hey Cameron, all, ... * The letter is only rejection of the proposal without offering an alternative way forwards. I strongly suspect the proposed standard would have received a much better reception from the broader OSGeo community (with the diverse viewpoints it typically has) if the proposal was more that a take it or leave it (partial?) description of what ESRI has done and is going to do anyway. If there was at least some willingness to engage with the broader community on interoperability within the standard (and how do you have interoperability if you aren't willing to budge from a pre-defined position anyway?). Perhaps ESRI didn't realise their approach was going to come across with an up you attitude (or maybe they did)? The impression I've got it that many people feel ESRI is treating the OGC as a rubber stamp body (which very much implies arrogant contempt) regardless of the merits of the proposal. Hopefully I've got it wrong and ESRI really just botched their approach on this one (why do I feel this is naive wishful thinking?). FWIW, I don't believe having an alternate incompatible standard must of itself be a deal breaker, if the proposed standard genuinely represents a viable attempt at interoperability. After all, the wonderful thing about standards is there are so many to choose from. ;) Lets just not pretend it's about genuine interoperability unless that really is the case. Regards, Tim Bowden ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss it's not only rejection in the letter, there is also a way forward that I took the liberty to suggest: /The components making up the ESRI Geoservice REST API provide natural blocks assignable to the matching SWGs. As for Part 6 of the ESRI Geoservice REST API, if to become a standard it needs to be discussed in the WCS.SWG for harmonization, clarification, and improvement. // / cheers, Peter -- Dr. Peter Baumann - Professor of Computer Science, Jacobs University Bremen www.faculty.jacobs-university.de/pbaumann mail: p.baum...@jacobs-university.de tel: +49-421-200-3178, fax: +49-421-200-493178 - Executive Director, rasdaman GmbH Bremen (HRB 26793) www.rasdaman.com, mail: baum...@rasdaman.com tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882 Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata. (mail disclaimer, AD 1083) ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] The OSGeo response to the proposed GeoServices REST API document [was: Would you be concerned ...]
Thanks Adrian for your email with your reasoned explanation. It's not often people take the time to provide such a thorough analysis. On May 9, 2013, at 1:56 PM, Adrian Custer acus...@gmail.com wrote: On 5/9/13 2:33 PM, Tim Bowden wrote: On Thu, 2013-05-09 at 13:20 -0300, Adrian Custer wrote: Hey Cameron, all, ... * The letter is only rejection of the proposal without offering an alternative way forwards. I strongly suspect the proposed standard would have received a much better reception from the broader OSGeo community (with the diverse viewpoints it typically has) if the proposal was more that a take it or leave it (partial?) description of what ESRI has done and is going to do anyway. Undoubtedly. This was as undiplomatic as they could have been. If there was at least some willingness to engage with the broader community on interoperability within the standard (and how do you have interoperability if you aren't willing to budge from a pre-defined position anyway?). And there would have been more participation at the OGC. Lots of folk were excited at the start but gave up when backwards compatibility was set in stone. Perhaps ESRI didn't realise their approach was going to come across with an up you attitude (or maybe they did)? The impression I've got it that many people feel ESRI is treating the OGC as a rubber stamp body (which very much implies arrogant contempt) regardless of the merits of the proposal. Much more likely, ESRI is trying to push through its standard, distinct from expecting the OGC to 'rubber stamp' it. They knew from the get go they were going to face this opposition. The only question is who is stronger. This is a good example of the limits of governance at the OGC. Really, a standard should not pass when there is concerted opposition to it. The process is designed to suspend when there is opposition (2 no votes), in an effort to build consensus. However, the ultimate decision is still a 50% + 1 vote; probably, it should be a super-majority of some kind. Having attended most of the first 50-ish OGC meetings and then a few here and there since, here's my perspective on the limits of governance. The problem is not so much the process (or wasn't, back in the day, it's become much more byzantine since then). The main problem is that most TC members either have no programming/architecture background or their expertise is fairly specialized. That means that for any given proposal, a small percentage of the members really understand it. Then, when it comes to a TC vote you have people voting based not strictly on technical grounds but also on business interests, political interests, even social interests. On top of that, I don't think that member companies are very knowledgeable about the policies and procedures and don't really know how to use their memberships to their best advantage. Taken together, this can lead to some fairly dysfunctional results. I believe that the Architecture Board (or whatever it's called now) was established in part to counter this effect. You'd have a bunch of knowledgable old hands benevolently watching over the output of the process who were going to make sure things hang together from a technical point of view. Perhaps the Architecture Board has been unable to provide sufficient guidance to the TC in this particular instance. Hopefully I've got it wrong and ESRI really just botched their approach on this one (why do I feel this is naive wishful thinking?). FWIW, I don't believe having an alternate incompatible standard must of itself be a deal breaker, if the proposed standard genuinely represents a viable attempt at interoperability. After all, the wonderful thing about standards is there are so many to choose from. ;) Lets just not pretend it's about genuine interoperability unless that really is the case. I doubt anyone is that naive. In the end, everyone wins if specs are vendor neutral but also allow vendors to differentiate themselves by providing different qualities in their implementations. If a spec is passed that is simply a thin veneer on top of an existing vendor's implementation, then that vendor has a head start over others. If the OGC members are collectively unwilling or unable to push back against this, then this kind of thing is the result. It's really a Darwinian microcosm within a mutually agreed upon set of rules. If the results are irrelevant, confusing, or outrageous, then over time the organization will suffer and become less relevant. Allan Regards, Tim Bowden cheers, ~adrian ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] The OSGeo response to the proposed GeoServices REST API document [was: Would you be concerned ...]
Adrian, Thanks for the in depth review. I admit I haven't read the document over thoroughly but even without doing so there are some obvious concerns. From a user perspective (my user), this appears to be a push to get their way of doing things stamped as a standard so they can let their users (e.g. government agencies) claim compliance with Open Standards without having to use WxS. I can see this first hand with my own personal experience trying to get WFS/GML to work with Arc (supposedly supported with special add ons) and government agencies thinking if they put up an Arc Service they've done their duty: https://services.gis.ca.gov/arcgis/rest/services/Government/CPAD_19/MapServer (Note the confusing url that implies MapServer software, and the lack of any non ESRI web service on the page) To me it looks like they are trying to get out of spending the money to fix their products so they place nice with all the existing services. I agree though, that simply turning ESRI away isn't a solution either, at least they came to the same standards body unlike the OASIS/ISO debacle over Office formats. Is there someone in the OGC community that could reach out and negotiate a plan to merge their work and ideas with the existing standards instead of creating a direct competition to what is already widely adopted. If they really want it to be a standard they have to be willing to compromise on some feature to make it more interoperable, in a sense kml did this by not including all the possibilities in the original spec. I also agree 50+1 is a bad bar for a standards body. Which reminds me that I dropped the ball on renewing my institution’s membership (though I don't think it had voting rights). Thanks, Alex On 05/09/2013 10:56 AM, Adrian Custer wrote: On 5/9/13 2:33 PM, Tim Bowden wrote: On Thu, 2013-05-09 at 13:20 -0300, Adrian Custer wrote: Hey Cameron, all, ... * The letter is only rejection of the proposal without offering an alternative way forwards. I strongly suspect the proposed standard would have received a much better reception from the broader OSGeo community (with the diverse viewpoints it typically has) if the proposal was more that a take it or leave it (partial?) description of what ESRI has done and is going to do anyway. Undoubtedly. This was as undiplomatic as they could have been. If there was at least some willingness to engage with the broader community on interoperability within the standard (and how do you have interoperability if you aren't willing to budge from a pre-defined position anyway?). And there would have been more participation at the OGC. Lots of folk were excited at the start but gave up when backwards compatibility was set in stone. Perhaps ESRI didn't realise their approach was going to come across with an up you attitude (or maybe they did)? The impression I've got it that many people feel ESRI is treating the OGC as a rubber stamp body (which very much implies arrogant contempt) regardless of the merits of the proposal. Much more likely, ESRI is trying to push through its standard, distinct from expecting the OGC to 'rubber stamp' it. They knew from the get go they were going to face this opposition. The only question is who is stronger. This is a good example of the limits of governance at the OGC. Really, a standard should not pass when there is concerted opposition to it. The process is designed to suspend when there is opposition (2 no votes), in an effort to build consensus. However, the ultimate decision is still a 50% + 1 vote; probably, it should be a super-majority of some kind. Hopefully I've got it wrong and ESRI really just botched their approach on this one (why do I feel this is naive wishful thinking?). FWIW, I don't believe having an alternate incompatible standard must of itself be a deal breaker, if the proposed standard genuinely represents a viable attempt at interoperability. After all, the wonderful thing about standards is there are so many to choose from. ;) Lets just not pretend it's about genuine interoperability unless that really is the case. I doubt anyone is that naive. Regards, Tim Bowden cheers, ~adrian ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] The OSGeo response to the proposed GeoServices REST API document [was: Would you be concerned ...]
Adrian, This is an exceptionally well written letter, which I believes captures what many of us in the OSGeo Community would like to say. You have provided an eloquent, unbiased, concise summary of the issues, covering the key technical issues. If an OGC voter only had time to read one thing before voting, I would recommend they read this email of yours. As such, I'd like to work with you to see what the best way would be to incorporate your text into our open letter at: http://wiki.osgeo.org/wiki/Geoservices_REST_API (assuming that would be ok with you). I'd like your text in this open letter, as I'm expecting it to have lots of OGC Voters reading it. I note that we already have a number of people have collated reasons for not voting for this standard. I suggest that we invite these authors to check if their concerns have been covered by your summary, and if so, remove their duplicate concerns. Anything left can either be added by Adrian Custer into his summary, or collected in a Further Comments section at the end. Adrian, What are your thoughts? On 10/05/2013 2:20 AM, Adrian Custer wrote: Hey Cameron, all, Cameron, you recently asked me to join your letter from the OSGeo to the OGC Members regarding the adoption of the proposed ESRI GeoServices REST API as an OGC standard. http://wiki.osgeo.org/wiki/Geoservices_REST_API#Open_Letter_to_OGC_and_voting_members Thanks. Your request has forced me to define my position, which has been a huge waste of my time, but was probably worth doing. My response has two sides, my position on the debate and my decision to participate in the letter. The first is my position on the actual proposed standard. The pros: * The OGC should be in the business of developing good standards, not of choosing which standards should be implemented. * The proposers of the document want to make a standard and have followed all the rules of the consortium. The work of any such group of members deserves serious, good faith consideration. * The need for an integrated suite of services using simple data, which is addressed (partially) by the document, is real. The proposed document is pushing the OGC on this issue. * The proposed document could be useful to a number of people. * The proposed document is not significantly more broken than the existing standards of the OGC. As an author of standards at the OGC, I know how totally impossible it is to write a good standard, so the weaknesses in the existing document seem more acceptable. The cons: - * The OGC is, de-facto, in the position of recommending the interoperable standards for geospatial services. The proposed document is not good enough, not widely enough implemented, and not publicly supported enough, to be considered at the same level as existing standards. * Adopting a standard implies a desire to maintain the standard but the desire to support this approach by the OGC membership is limited. The lack of collaboration on this version bodes ill for the future. * The overlap in functionality between the proposed services and the existing services, notably with the ongoing work to modularize the existing services, is almost 100 percent. However, compatibility is low. * There is already a published document: http://www.esri.com/library/whitepapers/pdfs/geoservices-rest-spec.pdf so there is no need for the document to be adopted as an OGC Standard merely for interoperability with the ESRI implemetation. * The document, as a new, separate effort, repeats mistakes which were made and since solved by the other services. * The document focuses on the past (notably with backwards compatibility and use of only GET/POST) not on the future. * The document needs a comprehensive editorial rewrite. (see at end) The problem for me, is that both simple answers are bad. A simple acceptance of the standard would introduce a new set of 'OGC approved' open services. The OGC approval might enable governments to buy a -new-name-here- solution instead of a W*S or a S*S solution. (On that, I am inclined to let them make their own mistakes.) The path forwards towards harmonizing the services is unclear. There is little good will towards the standard on behalf of the membership. Fixing this document in addition to fixing the W*S services will be a pain. Simply rejecting the solution would be bad for the OGC. It would place the OGC in the position of picking winners and losers in the standards business. It would mean that the OGC is stuck on the project of fixing the W*S standards to meet some nebulous future functionality without having any path to get there. It would discourage innovation and progress. Is there a third way? Well, actually, there is. The natural consequence of either decision is a renewed commitment towards trying to
