[OSGeo-Discuss] Would you be concerned if the "GeoServices REST API" became an OGC standard?

Adrian Custer acuster at gmail.com
Sat May 4 09:55:57 PDT 2013


Hey Barry,

There is no useful concept of a 'reference implementation' at the OGC.


The things the OGC calls 'reference implementation' are actually 
"example testing implementations." The word was incorrectly adopted by 
the testing group (pushed by those with commercial concerns). The 
testing group now wants to have multiple 'reference implementations' 
showing they are not really a 'reference' in the common understood 
meaning. I am trying to get the testers to change the terminology to 
avoid the semantic conflict with the general meaning of 'reference 
implementation.'

Critically, none of the implementations were vetted by the groups 
defining the actual standards documents so there is little relation 
between the implementation and the standard. It therefore makes little 
sense to think of 'reference implementations' at the OGC.


As far as "GeoServices REST", the default reference implementations are 
ESRI's since the document is merely defining how those implementations work.

~adrian




On 5/4/13 1:27 PM, Barry Rowlingson wrote:
> On Sat, May 4, 2013 at 11:46 AM, Cameron Shorter
> <cameron.shorter at gmail.com> wrote:
>
>> I'm wanting to hear whether people in the OSGeo community have strong
>> opinions regarding this proposed standard, and whether we as a
>> collective OSGeo community should make statements to the OGC, and voting
>> OGC members, stressing our thoughts.
>
> My current concern is that the standards documents are in a bunch of
> Microsoft Word files. And a bunch of Microsoft Word files that *crash*
> my current version of OpenOffice.... Oh the comedy of open standards
> being written using non-open file formats[1]
>
> The ironic comment of "standards are great - lets have more of them"
> possibly applies here.
>
> In terms of open source implementations, the google search
> "geoservices rest api github" doesn't find much, so I suspect the open
> source community is happy with its web APIs already. These guys:
>
> https://github.com/WSDOT-GIS/Traveler-Info-GeoServices-REST
>
>   appear to be implementing a GeoServices REST endpoint for their
> system, maybe they'd be willing to refactor their code out and develop
> it as a reference server implementation? But oh dear it seems to be
> written in C#.
>
>   I'm not sure what the term 'reference implementation' means here. Any
> difference in behaviour between an implementation and the spec is a
> bug with the implementation, yes? For that I don't think it matters if
> the "reference implementation" is open source or a black box - that's
> irrelevant to its compliance with the standard.
>
> However, a freely-available implementation does make it easier (and in
> some cases, possible) to write code that works practically. I wouldn't
> like to write a GeoServices client without a server to test it
> against. Without it my option is to check my client request is correct
> by comparing it with the standards document (in that unreadable Word
> document).  Imagine if the authors of the first web browsers hadn't
> had http servers to actually test against?
>
>   The advantages of an open source reference implementation are also
> the usual advantages of open source that we've been banging on about
> for years. Mismatches between open source implementations and
> standards docs can be fixed in minutes and released, and users don't
> have to wait six months for the next product update release, for
> example.
>
> Is there an open-source reference implementation of code to work with
> every aspect of the KML file standard? The situation seems analagous -
> a proprietary standard pushed to OGC and opened up.
>
> Barry
>
> [1] yeah this is probably wrong and MS got their file formats
> certified 'open' somehow... blah blah court case blah blah ISO voting
> blah blah
> _______________________________________________
> Discuss mailing list
> Discuss at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/discuss
>



More information about the Discuss mailing list