[OSGeo-Discuss] The OGC: clueless, uncaring, and still rocking to Prince.

[rburhum]

Dear Adrian,

I recently saw a reply that you made to a blog post I wrote recently.
Although the criticism were meant to be directed to the *OGC* as an
*organization*, I can tell by your comments, descriptions and overall tone,
that you felt *personally* attacked and offended. You have my sincere
apologies if you felt that way. This was never meant to be a personal
attack.

I would be happy to elaborate, with far more detail, each single one of my
comments/points. We can do this either publicly or in a private e-mail
exchange (whatever you feel is best). 

Based on your responses though, I have to admit that we have fundamental
disagreements in several aspects – and some serious ones at that.
 
- I would be happy to discuss XML vs JSON vs MessagePack conversations and
why the first of those is (lately) not adopted by any modern API. JSON is
the real winnder nowadays (for good reasons). In terms of serialization
frameworks, MessagePack has implementations in
Ruby/Python/Perl/C/C++/Java/Scala/PHP/Lua/JavaScript/Node.js/Haskell/C#/Objective-C/Erlang/D/OCaml/Go/LabVIEW/SmallTalk/etc.
I dare to say it is “somewhat” supported.

- I would be happy to discuss why security is more than certificate exchange
or username/password submission during requests.

- I would be happy to discuss why complexity of specifications hinders
adoption.  There are technical reasons why geojson and mbtiles are gaining
traction without much effort and GML is not. (Much love to all my friends
that were involved with GML – I apologize if this offends you).

- I would be happy to discuss why I think SQL (SQL:1999, or SQL:2003, or
SQL:2008 or SQL:2011) is a better choice for an API than a full fledged OGC
query language that tries to abstract querying. As a side comment, you are
correct at thinking that my reasoning here came from experience. Around 10
years ago I was sitting at my ESRI office and a co-worker came into the
office and asked me for help since he was in charge of implementing one of
the OGC WFS version specs. The nicest thing that I can tell you is that “it
was painful and unreasonable in many regards” and that it ended up requiring
to hire an “OGC consultant” to try to implement the spec as close as
possible (to *explain* – not to implement) 

- I would be happy to accept the fact that OGC does not have “reference
implementations”. That is, of course, as soon as the OGC itself stops using
that those terms. I think there was a misunderstanding with the reference
implementation licensing comment. Let me just say that there is plenty of
Open Source that is BSD or Apache licensed (for example, AFAIK, *everything*
from the Apache Foundation http://projects.apache.org/indexes/alpha.html).
But please, let’s leave licensing talks for the end.

- I would be happy to explain the different between a stateful and a
stateless architecture and why websockets are a paradigm shift for the web.
If you want to implement the same concepts of a spec without “being tied to
the web” or “web browsers” feel free to take “web” out of “websockets” and
just use sockets. The same stateful vs stateless architecture argument
remains.

- I would be happy to explain why SPDY is not “another protocol” but one of
the inspirations/guides for httpv2. We are still talking http here.

- I would be happy to explain WebSQL even though it died. Why you may ask?
Because there was only one implementation of the standard (sqlite) and the
standards organization (W3C) refused to make it a standard without a
competing implementation. I hope the irony of this situation doesn’t escape
you.

- I would be happy to explain why the OGC doesn’t have to fully re-invent
the wheel when it comes down implementing a Spatial DVCS. The fact that it
is “spatial” doesn’t mean it needs to be completely different. I would talk
to the GeoCouch guys that have a perfectly good replication model that works
or would also look at things like Git, Mercurial, PostgreSQL, MySQL or even
the ESRI Versioning and replication system. Replication/versioning is a
solved problem. We just don’t have a *standard* that defines how everyone
should implement it. Ironically, I can point out a couple of OGC members
that are experts in this field.

- I would be happy to explain why perhaps, after all these years, it is time
to stop ignoring temporal datasets and addressing some of the not so “low
hanging fruit”.

- I would thank you for calling me young! Although I am not sure I am
confused all the time. Well, perhaps 70% of the time I am! 

In all honesty, I have to admit though, the original post was written as a
quick reaction to another set of e-mails I received in regards to some OGC
decisions as of late. 

The truth is that, until last week, I equated the OGC as a standards body
that was meant to be equivalent to the W3C (except, of course, for GIS).
Sadly, this also means that I would expect a similar behavior/quality of
decisions from the OGC (maybe this is a mistake on my part?). If you look at
the working groups for the W3C,  http://www.w3.org/Consortium/activities you
will notice that the W3C is working on several standards for technologies
that do *not* exist or have not been implemented uniformly across the
various browsers (Device APIs, Web Events, Web Notifications, etc). Hence my
argument of “working for the future”.

The W3C doesn’t simply exist to ratify the format of a particular vendor as
a standard so the vendor can slap a logo that says “[x] standard” and be
able to check a box in some RFP (Request for Quote) somewhere. Now please,
don’t get me wrong. I am not saying that is why the OGC exists (that was not
the original intention), but among the GIS community there is a sentiment
that a couple of the last standards that have come out from the OGC may have
not been thought-through well enough. 

Let me get the elephant out of the room. I am explicitly talking about KML
and GeoServices REST as OGC standards. Although some people may
(voraciously) disagree with me, I cannot think of those as more than
standards that are politically motivated. 

Why? Because I cannot see the merits, from a *standards* point of view. 

Do I think the Google API is well designed? Yes I do! It is AFAIK, the most
widely used API in the world (stats from Google). Do I use it? I actually
do. I love it.

Yet the concept of having the OGC ratify Google’s Map API (or an OGC Bing
API) seems ludicrous. Do you see any resemblance with a GeoServices REST API
spec in this analogy?

Again, don’t get me wrong. I work a lot with ESRI software (I used to build
it) and with Google APIs (I use them all the time for consulting jobs). I
love combining technologies from these two vendors with Open Source stacks.
I always get amazing _practical_ results. Unlike many people in the OSGeo
list, I love using the ESRI APIs because I know them well and I see the
merits that they have in their particular use-cases.

And yet I believe standardizing (or going through process of attempting to
standardize in the case of GeoServices REST) is simply a credibility
harakiri. That is committed a second time.

I would love to hear the arguments that support KML and GeoServices REST as
OGC standards.

To me, it is simpler. 

Fool me once, shame on you. Fool me twice, shame on me.
http://xkcd.com/386/

Again, this is meant to be taken as a criticism of the OGC – and not you
personally (although the message was obviously directed to you).

With Best Wishes,

- Ragi




--
View this message in context: http://osgeo-org.1560.x6.nabble.com/The-OGC-clueless-uncaring-and-still-rocking-to-Prince-tp5052757p5052787.html
Sent from the OSGeo Discuss mailing list archive at Nabble.com.