<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hello Dret,<div><br></div><div>'<a href="http://tools.ietf.org/html/rfc6839">http://tools.ietf.org/html/rfc6839</a> is an attempt to make this a bit more structured, and then you could use application/geojson+json, making it both clear that it's GeoJSON, and JSON. but this would of course break compatibility with the current practice of using application/json, so maybe it's not such a great idea in the end for things that already are deployed.'</div><div><br></div><div>To be 100% honest I am not sure why application/geojson+json would break compatibility. If you are serving GeoJSON and using application/json and change to server application/geojson+json you are still returning the same thing, in this case GeoJSON. Isn't application/geojson+json a sub-set of application/json?</div><div><br></div><div>Thanks for the great discussion all.</div><div><br></div><div>-Billy</div><div><br><div><div>On Nov 3, 2013, at 10:35 AM, Erik Wilde <<a href="mailto:dret@berkeley.edu">dret@berkeley.edu</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">hello nelson.<br><br>On 2013-11-03, 09:25 , Nelson Minar wrote:<br><blockquote type="cite">It's too bad that MIME types only describe the encoding and not the<br>actual contents, but that's the way the standards work.<br></blockquote><br>that's not actually the case. that's the way some communities use them (semweb is one popular example), while others are using them differently. for RESTful web services, for example, many people are minting meaningful media types, instead of using very generic identifiers.<br><br><a href="http://tools.ietf.org/html/rfc6839">http://tools.ietf.org/html/rfc6839</a> is an attempt to make this a bit more structured, and then you could use application/geojson+json, making it both clear that it's GeoJSON, and JSON. but this would of course break compatibility with the current practice of using application/json, so maybe it's not such a great idea in the end for things that already are deployed.<br><br><blockquote type="cite">The main purpose<br>of that type is to signal the user agent how to decode the thing (ie:<br>it's JSON to turn into Javascript objects, not XML or HTML to turn into<br>DOM or an image or whatever.) It's up to the application to inspect the<br>object contents to determine what was in the JSON blob.<br></blockquote><br>again, that's a result of designing things in a certain way, and maybe not the best possible one. to me, using profiles actually seems like a pretty good compromise: it's backwards compatible to those who use application/json, but still exposes the fact that the format is more than just generic JSON.<br><br>cheers,<br><br>dret.<br><br>-- <br>erik wilde | <a href="mailto:dret@berkeley.edu">mailto:dret@berkeley.edu</a> - tel:+1-510-2061079 |<br> | UC Berkeley - School of Information (ISchool) |<br> | <a href="http://dret.net/netdret">http://dret.net/netdret</a> <a href="http://twitter.com/dret">http://twitter.com/dret</a> |<br></blockquote></div><br></div></body></html>