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
<[email protected]> 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
[email protected]
http://lists.osgeo.org/mailman/listinfo/discuss
_______________________________________________
Discuss mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/discuss
