tom at macwright.org
Mon Nov 4 14:51:33 PST 2013
I'm definitely +1 for just using application/json and not doing anything
unusual on top of it. For better or worse, there's popular code in the wild
that simply checks for 'application/json' and acts on it without any
special parsing logic. Signifiers of GeoJSON-ness like the `.geojson`
suffix and `type` property should be sufficient for most clients, and have
been in my experience.
On Mon, Nov 4, 2013 at 5:47 PM, Erik Wilde <dret at berkeley.edu> wrote:
> hello andrew.
> On 2013-11-04, 12:34 , Andrew Turner wrote:
>> I prefer post-fix the content type since geoJSON is a subset of JSON
>> For one, this makes it clear that it is `application/json` plus another
>> thing '+geo'. Additionally this would permit multiple suffix (e.g.
>> 'application/json+geo+ld'. Last, practically code can evaluate
>> 'contenttype =~ /application\/json/ and it would account for subsets.
> i see your motivation, but it might be a better idea to stick to what
> http://tools.ietf.org/html/rfc6839 is saying. there are no multiple
> suffixes in that system, and the generic part goes last. this might not be
> the most sophisticated system in the world, and media types in general are
> not a very well modeled space. but GeoJSON probably shouldn't design and
> define its own way of how media types work. and given the above RFC, i am
> pretty confident that a registration request for application/json+geo would
> be rejected at this point in time.
> erik wilde | mailto:dret at berkeley.edu - tel:+1-510-2061079 |
> | UC Berkeley - School of Information (ISchool) |
> | http://dret.net/netdret http://twitter.com/dret |
> GeoJSON mailing list
> GeoJSON at lists.geojson.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the GeoJSON