[GeoJSON] Content-type

[Andrew Turner]

I prefer post-fix the content type since geoJSON is a subset of JSON

 application/json+geo

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.

Andrew


On Sun, Nov 3, 2013 at 9:07 PM, Erik Wilde <dret at berkeley.edu> wrote:

> hello billy.
>
>
> On 2013-11-03, 17:03 , Billy Newman wrote:
>
>> 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?
>>
>
> logically it is and the structured suffix makes it look a little bit as if
> it were, but strictly speaking, media types have not hierarchy other than
> the type/subtype structure, so application/json and
> application/geojson+json are completely different things. whether over time
> the structured suffixes will create a defacto structure of registered media
> types that might eventually be codified is hard to tell, but as it stands
> now, when you ask for application/geojson+json, an old server would just
> say "no, i only have application/json", and there would be no matching
> process to connect those two in any way.
>
> thinking of it, maybe something like http://tools.ietf.org/html/rfc4647should exist for media types as well, and then could take structured
> suffixes into account. but the problem also is that different communities
> have different practices around how they use media types. in RDF, for
> example, media types play a minimal role, just distinguishing between
> various serializations of the same generic metamodel, whereas other
> communities have adopted different practices, making media types more
> meaningful, semantically speaking. it might actually be pretty hard to
> unify all of those practices. which is not to say that it might not be a
> valuable exercise as an I-D, so that it's captured in one place. but it
> might turn to be an exercise where the end result is that there is no
> single simple unified model that could be used across all domains, so what
> remains would be the simple matching process as defined by HTTP.
>
> http://tools.ietf.org/html/draft-ietf-httpbis-p2-
> semantics-22#section-5.3.2
>
>
> cheers,
>
> dret.
>
> --
> 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
> http://lists.geojson.org/listinfo.cgi/geojson-geojson.org
>



-- 
Andrew Turner
t: @ajturner
b: http://highearthorbit.com
m: 248.982.3609
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geojson.org/pipermail/geojson-geojson.org/attachments/20131104/f107cccf/attachment.htm>