[OSGeo-Standards] [RESTful-Policy.SWG] Encodings and REST

[Volker Mische]

I'd like to add that I'm sorry posting the news on Twitter although it
was just a preview document, that is only available to SWG members. I
thought it's already the final response to the RFC when I posted it.

Cheers,
  Volker

On 10/21/2012 09:11 PM, Carl Reed wrote:
> Evan -
> 
> As part of the OGC standards process, a standards working group is required 
> to discuss and vote on all comments received during the public comment 
> period. Any comment that is accepted will result in changes to the candidate 
> standard. They also need to develop a document that collates all comments as 
> well as the SWG decisions with regard to each comment. Finally, the SWG is 
> supposed to contact each of the individuals that submitted comments as to 
> the disposition (accept, accept with modification, future work, reject) of 
> the comment.
> 
> Hope this helps clarify the OGC process.
> 
> Regards
> 
> Carl
> 
> 
> -----Original Message----- 
> From: Even Rouault
> Sent: Sunday, October 21, 2012 12:34 PM
> To: standards at lists.osgeo.org ; restful-policy.swg at lists.opengeospatial.org 
> ; oab at lists.opengeospatial.org
> Cc: Clemens Portele
> Subject: Re: [OSGeo-Standards] [RESTful-Policy.SWG] Encodings and REST
> 
> 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. "
> _______________________________________________
> Standards mailing list
> Standards at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/standards 
>