<p dir="ltr">I think we must review how openoffice become iso standared, and microsoft that behave like esri, want new standard called msoffoce xml.</p>
<p dir="ltr">He submit his docx, xlsx, etc, which he said better and more complete, but anyone adopt.<br></p>
<p dir="ltr">For respect, i hope we can follow this model. Esri no need standard, or using his api as new standard, that is bad.</p>
<p dir="ltr">Happen in java world, people in community use struts as standard in 1999, competitor come, smiliar case, a standard body inside sun organization called jcp, play with new standard called jsf. Boom. Oracle and sun make standard from new standard, and reject struts or action framework or an adoption from html request response, this case happen several time by them, jdo, ejb. That bad for ecosystem, none use esp they, and marketshare still low until today.</p>
<p dir="ltr">My proposal if the current standard can be extend, that is better, with esri's new standard rather create one, esp this is a ms office in gis world, dangerous for ecosystem, this is about marketshare and business in their side.<br>
</p>
<p dir="ltr">I prefer they submit to iso or oasis.<br></p>
<p dir="ltr">F</p>
<div class="gmail_quote">On May 5, 2013 4:21 AM, "Cameron Shorter" <<a href="mailto:cameron.shorter@gmail.com">cameron.shorter@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Adrian,<br>
Thankyou, I was hoping that someone such as your self with insights into the standard would explain the details. You email has been a great help.<br>
<br>
I'm also hoping that someone will provide a more detailed comparison of the similarities / differences, to help the rest of the community understand what is happening.<br>
<br>
On 05/05/13 02:43, Adrian Custer wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Dear Cameron, all,<br>
<br>
There is indeed a massive conflict at the OGC related to this proposed standard and it may be useful to inform this list about that conflict and the process.<br>
<br>
However, I am unsure how expanding the *discussion* here helps.<br>
<br>
<br>
<br>
<br>
<br>
The proposed standard aims to document a series of web services and a JSON based data exchange format. The standard comes in eight parts<br>
<br>
12-054r2 GeoServices REST API - Part 1: Core<br>
12-055r2 GeoServices REST API - Part 2: Catalog<br>
12-056r2 GeoServices REST API - Part 3: Map Service<br>
12-057r2 GeoServices REST API - Part 4: Feature Service<br>
12-058r2 GeoServices REST API - Part 5: Geometry Service<br>
12-059r2 GeoServices REST API - Part 6: Image Service<br>
12-060r2 GeoServices REST API - Part 7: Geoprocessing Service<br>
12-061r2 GeoServices REST API - Part 8: Geocoding Service<br>
and there are also<br>
12-068r2 GeoServices REST API - JSON Schemas and Examples<br>
<br>
The documents describe the functioning of a set of web services, developed originally by ESRI, and the JSON format for many objects, also defined by ESRI, and used by those services.<br>
<br>
The OGC request for comments (now closed) is here:<br>
<a href="http://www.opengeospatial.org/standards/requests/89" target="_blank">http://www.opengeospatial.org/<u></u>standards/requests/89</a><br>
with each of the documents.<br>
<br>
<br>
<br>
<br>
Note that Cameron was either unclear or incorrect in his presentation of where the standard now stands.<br>
* The document was released for public comment. (see above)<br>
* A response to all the comments was issued. (however incomplete)<br>
* The document was then released for a vote.<br>
* The vote was suspended because two 'no' votes were heard.<br>
* A response was issued to the 'no' votes.<br>
* The vote was resumed<br>
* The vote was (re) suspended because two additional 'no' votes<br>
were heard, with new arguments.<br>
<br>
=> the vote is current suspended awaiting<br>
(1) a response to the new reasons, and<br>
(2) a decision of what to do next by the leadership of the<br>
OGC technical committee (where all this work happens),<br>
since we have not yet faced such lack of consensus.<br>
<br>
<br>
<br>
<br>
The proposed standard has been controversial from the start at the OGC. The controversy, as best as I can tell, centers on the following issues:<br>
* no backwards incompatible changes were allowed,<br>
* no work was done to integrate the proposed services with existing<br>
OGC services (W*S, ...),<br>
* the only implementations are by ESRI and its partners,<br>
* the name of the standard and services are not accurate or distinct.<br>
<br>
Banning backwards incompatible changes is controversial both because it blocked collaboration at the OGC (which essentially had to approve the ESRI implementation as is) and because it prevented things like using GeoJSON where appropriate. Also, going forwards, backwards compatibility will have to be maintained giving the existing implementations (i.e. ESRI's) a huge advantage in defining extensions (ESRI already has a number in the pipeline).<br>
<br>
The lack of integration with existing services is controversial both because they made no effort to work with the existing working groups and because it splits the work of the OGC into competing efforts. There is no clear path forwards towards harmonization despite the fact that most groups working on OGC Services are tackling issues in the same area (simple services, JSON exchange format, REST design).<br>
<br>
The dominance of ESRI is controversial both because the working mode lacked any collaborative spirit and, perhaps most critically, because this is seen as a way through which ESRI can bring its own service onto an equal footing with the current, public OGC standards in the government procurement game. Governments are shifting towards requiring that all spatial software conform with published, open standards; the proposed standard, if adopted, would allow ESRI to push its own software as also an "Open Standard" and compete on an unequal footing with implementations of the software being worked on by everyone else.<br>
<br>
The name of the standard 'GeoServices REST API' and the services are controversial for many reasons. The 'GeoServices' moniker is non-descript (many OGC standards are for geospatial services) and matches the current ESRI marketing terminology. 'REST' is a buzzword and implies a lot of design work which has not been done (and is happening elsewhere at the OGC); furthermore, if REST is about the design of a service's behaviour (that the service acts based on the transfer of representations of resources), then the word does not relate to an 'API'. Finally, the 'API' word does not really describe the standard which is describing a number of services and data exchange formats. The names of each service, e.g. either 'Map Service' or 'GeoServices Map Service' is problematic: how do we make sure that people know the difference between the 'OGC Web Map Service' and the 'OGC GeoService Map Service' ?<br>
<br>
<br>
However, despite these criticisms, note that a number of members of the OGC members feel that the OGC should be in the business of releasing standards and letting the marketplace decide which standards to adopt, implement, and use.<br>
<br>
My personal feeling is that the name must be changed to clearly separate this set of services from the others. Beyond that, I am not against a new competing standard, even despite the huge advantage it gives ESRI in a market it already dominates. However, I would not mind seeing the standard fail, if only to show groups the consequences of trying to railroad documents through the standards group rather than building support for them through open collaboration.<br>
<br>
<br>
<br>
Which brings us to OSGeo and what useful contribution it could make to the debate. Simply rehashing the issues above is not going to be useful to anyone. If new ideas arise, or a large, common position emerges on the issue, I'd be glad to inject them into the OGC discussion.<br>
<br>
I suspect there is at least a week before voting resumes, although the rules going forwards are not yet clear.<br>
<br>
cheers,<br>
~adrian<br>
<br>
<br>
<br>
<br>
On 5/4/13 7:46 AM, Cameron Shorter wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
OSGeo Community,<br>
<br>
Currently, voting OGC members are to decide whether to accept the<br>
"GeoServices REST API" as an OGC standard. This is already a contentious<br>
issue, with 13 votes for, and 10 votes against, 72 outstanding votes,<br>
with voting halted temporally, being reopened again in a few days, and<br>
closing 2 weeks after that. [1]<br>
<br>
I'm wanting to hear whether people in the OSGeo community have strong<br>
opinions regarding this proposed standard, and whether we as a<br>
collective OSGeo community should make statements to the OGC, and voting<br>
OGC members, stressing our thoughts.<br>
<br>
If there is sufficient interest, I'll raise this issue with the OSGeo<br>
Board, with the intent of drafting a statement on behalf of OSGeo.<br>
<br>
As background:<br>
* "The API was initially developed by Esri and implemented on the ArcGIS<br>
for Server platform." [2]<br>
<br>
* The proposed GeoServices REST API specification overlaps with most OGC<br>
standards already deployed, including: WMS, WMTS, WCS, WFS, SE/SLD,<br>
CS/W. This effectively means that for most use cases covered by the<br>
GeoServices REST API, applications would now have two standards to<br>
support. Also, spatial infrastructure programs will be impacted, as OGC<br>
compliance won't necessarily equate to interoperability.<br>
<br>
* Most (all?) current OGC web service standards to date have an Open<br>
Source reference implementation, which was often (always?) part funded<br>
by OGC testbeds, and open source implementations were tested against<br>
proprietary implementations during OGC testbeds. As far as I'm aware,<br>
there has been very little up-take from the Open Source community of the<br>
"GeoServices REST API", and I'm unaware of any testing of non-ESRI<br>
applications during OGC testbeds. (Someone may be able to correct me here).<br>
<br>
[1]<br>
<a href="https://portal.opengeospatial.org/?m=projects&a=view&project_id=82&tab=5&subtab=0" target="_blank">https://portal.opengeospatial.<u></u>org/?m=projects&a=view&<u></u>project_id=82&tab=5&subtab=0</a> <br>
<br>
(OGC member login required. Votes counted as at 4 May 2013)<br>
<br>
[2] <a href="http://www.opengeospatial.org/standards/requests/89" target="_blank">http://www.opengeospatial.org/<u></u>standards/requests/89</a><br>
<br>
</blockquote>
<br>
______________________________<u></u>_________________<br>
Discuss mailing list<br>
<a href="mailto:Discuss@lists.osgeo.org" target="_blank">Discuss@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/discuss" target="_blank">http://lists.osgeo.org/<u></u>mailman/listinfo/discuss</a><br>
</blockquote>
<br>
<br>
-- <br>
Cameron Shorter<br>
Geospatial Solutions Manager<br>
Tel: <a href="tel:%2B61%20%280%292%208570%205050" value="+61285705050" target="_blank">+61 (0)2 8570 5050</a><br>
Mob: <a href="tel:%2B61%20%280%29419%20142%20254" value="+61419142254" target="_blank">+61 (0)419 142 254</a><br>
<br>
Think Globally, Fix Locally<br>
Geospatial Solutions enhanced with Open Standards and Open Source<br>
<a href="http://www.lisasoft.com" target="_blank">http://www.lisasoft.com</a><br>
<br>
______________________________<u></u>_________________<br>
Discuss mailing list<br>
<a href="mailto:Discuss@lists.osgeo.org" target="_blank">Discuss@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/discuss" target="_blank">http://lists.osgeo.org/<u></u>mailman/listinfo/discuss</a><br>
</blockquote></div>