Re: [OSGeo-Discuss] The OGC: clueless, uncaring, and still rocking to Prince.
Hello, What a decent mail. Thanks. All these topics sound good but each is worth its own detailed discussion. Some might be fascinating and they would then take a while and getting each started productively would be hard. Face to face, it might be different: quicker, easier to skip ahead, possible to find the interesting bits. Probably, I'd learn a lot. Unlike you, I doubt we disagree about that much on the technological side; more likely, we are considering different target audiences, with different restrictions, and have a different vision of the solution space. But then, I would rather spend that time elsewhere, like on trying to address issues with an existing OGC standard. Also, it would be hard for me to figure out effective language in response to so many paragraphs starting with the first person pronoun and setting up confrontation rather than building room for exploration. So perhaps face-to-face someday, where it would be possible to see if we could discuss productively, but not now and by text. Thanks for the offer. The personal offense is minor, not worth dwelling on. Your vision of the OGC is still puzzling but really I don't care. The OGC will make lots of mistakes, write lots of crummy standards, and so on. If adopting ESRI's pet standard destroys the OGC and all open geospatial standards with it, then so be it; they were too fragile to begin with. But I think it won't. Whatever happens, the OGC will survive, open standards are still needed, and life will go on. Ultimately, the OGC is just a bunch of people trying to get a good basis for agreement down on paper and then a bunch of organizations voting on whatever is produced. The people do their best; the organization vote their interests. That kind of setup lives or dies by the quality of the people in it. Thankfully there are some good people so there is some stuff of good quality in the mix. So, to the crux of your vent, it actually turns out that many are aware of most of the issues you mention, and several are actually trying to address them. So before throwing out some solution and spewing about why the OGC hasn't adopted it already, it might be more productive to ask: 'hey this problem seems kind obvious to me, have you all seen it and figured out how to tackle it?' Then, it might even turn out that there is work being done at the OGC, at a particular scale and pace due to the circumstances of that work. But the 'someone should do something the way I want it done already' doesn't really work in much of the world I have seen. hoping our paths do cross someday, ciao, ~adrian On 5/12/13 10:45 PM, rburhum wrote: 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 no
Re: [OSGeo-Discuss] The OGC: clueless, uncaring, and still rocking to Prince.
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 worki
[OSGeo-Discuss] Last chance to reject "Geoservices REST API" standard
Next Wednesday, the OSGeo Board will deliver an Open Letter to the OGC and OGC voting members, with multiple signatures, demonstrating the large number of people concerned about the negative consequences associated with making the "Geoservices REST API" an OGC standard. The "GeoServices REST API" was initially developed by ESRI and implemented on the ArcGIS Server platform before going through the OGC process. It significantly overlaps with OGC's existing W*S services, but isn't based upon these existing standards. Consequently, we have grave concerns that the two competing sets of standards, which essentially cover the same use cases, will have far reaching, detrimental impacts on interoperability, complexity, and costs within the spatial industry, including being bad for Geospatial Open Source software. Many people, including leaders of OSGeo and related communities, have already signed this letter. Thankyou. If you agree that "Geoservices REST API" will be bad for OSGeo and/or the greater spatial community, then please help us deliver this concern to OGC voters before they vote. Add your signature to the Open Letter [1] before we deliver it on Wednesday 15 May 2013, and forward this message onto other OSGeo communities. (I notice that messages from this thread are being forwarded to the Spanish OSGeo email list. Thankyou.) If you are looking for a deep analysis of the issues, I suggest reading the open letter which is now draft complete [1]. [1] http://wiki.osgeo.org/wiki/Geoservices_REST_API -- Cameron Shorter Geospatial Solutions Manager Tel: +61 (0)2 8570 5050 Mob: +61 (0)419 142 254 Think Globally, Fix Locally Geospatial Solutions enhanced with Open Standards and Open Source http://www.lisasoft.com ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
[OSGeo-Discuss] The OGC: clueless, uncaring, and still rocking to Prince.
Hey all, One of you probably has some clue who this character is who spews forth his "The OGC is Stuck in 1999" the OSGeo planet. If so, you might forwards this his way , if you feel he'd appreciate someone's reaction to his rant. Mr. Geo-preneur, Back in the early days of computer networking, we used to have these things called 'names' and other things called 'addresses' which used to be very helpful to help us interact. I discover, in the modern way of following links through to your 'blog' and your 'about me' page, that you have moved on from such primitive forms of being to things like 'twits' and 'inlinks'. Unable to deal with such modern ways and stuck on the wrong side of those pesky login screens, I cast this out to the community hoping it may float your way. Lovely rant this, your "The OGC is Stuck in 1999;" a classic spew. Too bad, really, because there are some nice links in there, a good video, some ideas worth hashing out, and other goodness. But the overall tone, nay shit-spew, reads like the ejection of a twelve year old, full of energy, naive, and not really old enough to carry a discussion. As a result, since you are pissing on my work without so much as asking what is going on, I'll assume this mail will only serve to teach me something and therefore, I'll write my reaction not addressed to you but rather to, and for, myself. You are surely full of knowledge, enthusiasm, and good intent. Perhaps, if we ever meet, we will find the similarities that link us. Until then, thanks for the useful stuff in your post; I'll now try to extract that from the rest of your text. So Adrian, what's in this thing? Standards should be written for the future – not the present Lovely reminder of Dan's wise rebuke, back at the bar counter in Berkeley, or maybe Albany: "Adrian, you keep using that word 'should.' There's no 'should.' There's only what there is and what you are going to work really, really hard to make happen." "an unecessary ... bureaucracy ... that is truly killing innovation" This non-sequitur I can ignore since there is actually little inefficiency in the adoption of standards. I can ignore the conclusion since the lack of innovation is not because it is killed by the OGC. Produced as a throw away sentence; I'll consume it by tossing it away. OGC is making "standards" that are ... Okay that's a core critique, well except for the 'whole bunch of protocols' which is probably at the wrong level of the networking stack, a confusion that comes back later. * outdated: => cheap criticism, no content, move on. And what 'standards' are we really talking about? Those that are outdated perhaps. * overly complicated: => indeed, which gave rise to the whole modularization push at the OGC currently. Good, that still seems like the right track. * reference implementation: => no such thing in reality, despite the name being used. Luis B. really needs to grok the confusion generated by the testing group's misuse of the 'reference implementation' meme. That was a real victory of the commercial folk over the best interests of the community at large. * a whole bunch of protocols: => this confusion is key. The specs were never really trying to define "protocols". We probably have done it for the open web, essentially by focusing on the lowest common denominator system of exchange system, but that was probably not our intent. Now, we should really be pushing for experimentation and encouraging the successes to land as additional communication options. Of course, this is the whole point of the modularization push, so we are on the right way forwards for that too. Still, there's something there that needs to be clarified to ourselves and to the public at large. So it looks like there needs to be some clarification. Probably we need some kind of, 'What the OGC is up to these years' since the young probably don't have the generous impulse 'whatever they are up to perhaps they are making progress and doing good work, we should ask before assuming the worst'. XML Datastores were all the academic hype back in the day ... That's cool to think about; and about the fatal tendency of standards writers chasing the latest hotness. Makes me wonder again of that Semnatic Web, and will it ever fly or, if not, why not. And, of course, it clashes directly with the 'write for the future' thread: yep, that's a tension in this line of work. Filters === SQL === XPath !? That sounds like it comes from experience. I don't get it but certainly recognize the complexity is huge. Passing SQL queries as a solution? Well that certainly violates to the 'don't impose an implementation.' Perhaps that's just facing reality that they all *are* SQL databases. What of nosql, though? Well, this is out of my realm of expertise but I can se
