[OSGeo-Standards] Encodings and REST

[Joshua Lieberman]

Concerns about consistency here and elsewhere are certainly issues that the OAB has and will take up. There is also a widespread consensus, I think, that multiple implementations are incredibly important for a standard specification to be a success. Any OGC member or group of members may propose almost anything. It is really up to the rest of the members whether a consensus develops to adopt what is proposed, and up to the wider community whether to make use of it.

Best,

Josh

-----Original Message-----
From: restful-policy.swg-bounces+jolieberman=deloitte.com at lists.opengeospatial.org [mailto:restful-policy.swg-bounces+jolieberman=deloitte.com at lists.opengeospatial.org] On Behalf Of Jeff Harrison
Sent: Sunday, October 21, 2012 6:57 PM
To: Even Rouault
Cc: oab at lists.opengeospatial.org; restful-policy.swg at lists.opengeospatial.org; standards at lists.osgeo.org
Subject: Re: [RESTful-Policy.SWG] [OSGeo-Standards] Encodings and REST

Even,

This is an excellent point, one that likely echoes the questions many other have as well...

Even wrote:  'I had exposed my concerns about the lack of consistency of the new proposal with existing OGC standards. Readinghttp://www.opengeospatial.org/projects/groups/oab , I see that "Specifically, the OGC Architecture Board works with the TC and the PC to insure architecture consistency of the Baseline". I would be indeed very interested in hearing how the new proposal is architecturely consistent with the baseline (*)

WMTS was an example of how OGC standards could be amended to embrace REST. The new proposal takes a completely different route.'

Regards,
Jeff

Sent from my iPhone

On Oct 21, 2012, at 2:34 PM, Even Rouault <even.rouault at mines-paris.org> wrote:

> Le samedi 20 octobre 2012 14:54:34, Arnulf Christl a écrit :
>> Folks,
>> I neither followed the discussion closely not the decision process of
>> the SWG. Can somebody summarize the rationale of the Geoservices REST
>> API group for not implementing GeoJSON but going down another route?
>> 
>> Somehow it seems like OGC is becoming just yet another party in the
>> general noise of format proliferation. We did better in other areas,
>> how come we cannot stay on top of this one?
>> 
>> This is pretty clear language, how are we going to address it?
>> https://twitter.com/vmx/status/259275792817741824
>> 
>> Apparently this comment by Volker Mische (who we know as supportive to
>> the OGC) is receiving a lot of positive support in the broader
>> geospatial IT crowd. Ignoring is not a solution.
> 
> Hi,
> 
> I'm unfortunately not very aware of the OGC processes, but will all the
> comments that have been posted on
> http://lists.opengeospatial.org/pipermail/requests/ in July and August 2012 be
> answered, or did they just land in a black hole ? There were pretty good
> points exposed by a great diversity of people, that shouldn't be ignored IMHO.
> 
> I had exposed my concerns about the lack of consistency of the new proposal
> with existing OGC standards. Reading
> http://www.opengeospatial.org/projects/groups/oab , I see that "Specifically,
> the OGC Architecture Board works with the TC and the PC to insure architecture
> consistency of the Baseline". I would be indeed very interested in hearing how
> the new proposal is architecturely consistent with the baseline (*)
> 
> WMTS was an example of how OGC standards could be amended to embrace REST. The
> new proposal takes a completely different route.
> 
> Finally, I second Volker on the lack of transparency of the process. It is
> good that OGC standards are open when they are finished, but it would be much
> better if their elaboration was truly open. Otherwise there is always the
> uneasy feeling that money and market considerations take over technical merit.
> 
> Best regards,
> 
> Even
> 
> (*) Hint: it is not. See my own comments of
> http://lists.opengeospatial.org/pipermail/requests/2012-July/000166.html :
> Quoting 12-062r1, "While it would be possible to develop new versions of the
> OGC Web Services standards using a consistent framework and with support for
> JSON representations and a RESTful "binding", this will likely take significant
> time due to the unresolved REST-related discussion items, the current
> organization of OGC SWGs based on the individual standards and the
> fragmentation into separate standards. "
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/standards/attachments/20121022/bf7abb40/attachment.html>