
<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Apr 26, 2013, at 9:51 AM, Jerry Sievert <<a href="mailto:jerry@legitimatesounding.com">jerry@legitimatesounding.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">I for one, would be very sad to see GeoJSON go the way of OAuth:<div><br></div><div><a href="http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/">http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/</a><br>

</div><div><br></div><div style="">GeoJSON is clean, flexible, and easy to implement and work with (we use it as the base commonality in Terraformer - <a href="https://github.com/esri/Terraformer">https://github.com/esri/Terraformer</a>), and I would hate to see a standards body destroy that.</div>

</div></blockquote><br></div><div>A bummer indeed, though one thing GeoJSON has going for it that OAuth doesn't is that its scope is almost universally recognized as being small. There is little competitive advantage to be gained by stuffing gobs of marginal features into the specification that all implementors must support. I would expect GeoJSONs tutelage inside of IETF to be rather benign simply due to the fact that GeoJSON represents a well-settled argument with a track record to protect. As long as we don't rip things up too much with the removal of the crs member, if that has traction, I would hope the only efforts inside of IETF related to GeoJSON in the future are simply ones that bring the specification in line with other specifications without internal disruption. </div><div><br></div><div>My guiding example here is GeoTIFF. Like GeoJSON, GeoTIFF simply extends an existing specification -- TIFF -- to sprinkle geographic dust on it. As a specification, it is widely used. As a working group around a common agreement, it is long dead. There are a number of things that are necessary to keep GeoTIFF moving forward that can't really be done because it doesn't live inside a standards body that can assume the authority to kick it forward. An individual or business might try to do this (and more than a few have), but they're swimming upstream against the inertia of an entire industry being willing to leave things alone out of laziness. That is fine, and at one level works quite well, but at another, it means that the leakage that happens around the specification gives people incentive to look for something better without the compatibility benefit. It also means that other specifications cannot build upon it for ongoing evolution (ASPRS LAS, GeoJP2, others?).</div><div><br></div><div>Let's not be GeoTIFF. To do that, this mailing list pretty much needs to stay alive forever, and the authors need to be around to answer questions about our intent and the future direction of the specification indefinitely. Or, we could hand things off to IETF and allow people who care enough to start participating to jump in.</div><div><br></div><div>Of all the standards bodies, including OGC, IEEE, ASTM, W3C, and IETF, the IETF seems the sanest and the best fit for GeoJSON with respect to other standards it leverages. OGC might be a natural home, at least in terms of subject matter and referentiality, if we weren't antithetical to its established culture and it to us. All are subject to the tyranny of the majority that your link demonstrates, however.</div><div><br></div><div>Howard</div></body></html>