<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">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.<br><br>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.<br><br>2. As Adrian mentions, control of the KML standard did not remain with Google, but was vested in the OGC.<br><br>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<br>
 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".<br>  <br>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.<br><br>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. <br><br>Has the OGC ever previously ratified a standard it does not then control?<br><br>Who decides on ERestful v1.1, etc., OGC or ESRI? If OGC cannot overule ESRI, then this should not be an OGC standard.<br><br>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<br>
 controlled rather than ESRI controlled standard, please correct me!!<br><br>Brent Wood<br><br><br><br>--- On Sat, 5/11/13, Adrian Custer <acuster@gmail.com> wrote:<br><br>From: Adrian Custer <acuster@gmail.com><br>Subject: Re: [OSGeo-Discuss] The OSGeo response to the proposed "GeoServices REST API" document [was: Would you be concerned ...]<br>To: "Miles Fidelman" <mfidelman@meetinghouse.net>, "OSGeo Discuss List" <discuss@lists.osgeo.org><br>Date: Saturday, May 11, 2013, 5:40 AM<br><br>On 5/10/13 12:25 AM, Miles Fidelman wrote:<br>> Adrian Custer wrote:<br>>> On 5/9/13 2:33 PM, Tim Bowden wrote:<br>>>> On Thu, 2013-05-09 at 13:20 -0300, Adrian Custer wrote:<br>>>>> Hey Cameron, all,<br>>>>><br>>>> ...<br>>>>> <br>    * The letter is only rejection of the proposal without offering an<br>>>>>       alternative
 way forwards.<br>>>><br>>>> I strongly suspect the proposed standard would have received a much<br>>>> better reception from the broader OSGeo community (with the diverse<br>>>> viewpoints it typically has) if the proposal was more that a "take it or<br>>>> leave it" (partial?) description of what ESRI has done and is going to<br>>>> do anyway.<br>><br>> Out of curiosity, how does this compare to the process by which KML<br>> became an OGC standard?<br><br>That was the first really contentious issue I experienced at the OGC. It <br>is related to the current situation in that the KML experience seems to <br>have encouraged ERSI to try to push GeoServices through.<br><br>However, I did not much care at the time so I did not follow the issues<br> <br>and controversy. I gather there was a feeling that KML duplicated other <br>standards at the OGC and mixed data with presentation in a poorly
 <br>structured way. I also vaguely remember that there was more of a feeling <br>that Google really wanted to hand off the standard to the OGC. But <br>again, I am not sure about any of this; I have never even seen a KML <br>document.<br><br>~adrian<br><br>><br>>><br>>> This is a good example of the limits of governance at the OGC. Really,<br>>> a standard should not pass when there is concerted opposition to it.<br>>> The process is designed to suspend when there is opposition (2 no<br>>> votes), in an effort to build consensus. However, the ultimate<br>>> decision is still a 50% + 1 vote; probably, it should be a<br>>> super-majority of some kind.<br>>><br>> I've always found the OGC process to be rather broken.  But then I'm a<br>> big fan of the<br> IETF approach - bottom up, "rough consensus and running<br>> code," a progression from experimental to recommended to mandatory,
 but<br>> only after a long incubation period - and don't even think of using the<br>> word standard until there are at least 2 interoperable implementations.<br>><br>> Miles Fidelman<br>><br><br>_______________________________________________<br>Discuss mailing list<br>Discuss@lists.osgeo.org<br>http://lists.osgeo.org/mailman/listinfo/discuss<br></td></tr></table>