1014Re: MIME types
- May 6 7:17 AMNo offense, but I think the replies thus far have missed Kris'
point. Kris is trying to get opinions on additional MIME types for
specific applications of JSON. These aren't necessarily messaging
envelopes and are still platform-agnostic. These are situations
where JSON is the format but the structure is important. Examples
from the XML world:
- ATOM: "application/atom+xml"
- XHTML: "application/xhtml+xml"
- XSLT: "application/xslt+xml"
- SVG: "image/svg+xml"
As you can see, these are all valid XML formats but it makes sense
due to their profileration to give them a MIME type that allows
better assumption of a subset of XML. I wouldn't want to interpret
SVG as an XHTML document and such it is nice to be able to
communicate between client-server the "types" that are accepted.
As I see it, opinions on this will more or less fall into three main
1) avoid MIME variants at all costs
2) standardize and use for every standardized variant
3) standardize and use sparingly where justified
There is the strict purist/minimalist perspective which would suggest
#1. This has the advantage of remaining simple, pure and keeps JSON
as just JSON. I can respect that. And judging by Kris' question he
is probably okay with that as well if that is the group concensus.
There are circumstances that #2 or #3 would be nice however. For
instance when I make a request for JsonML, it is nice to be able to
inform the server that as a client I can accept a JsonML response
(and in response that the format is actually JsonML and not just JSON
data which must be processed differently). This is a more specific
requirement than just being able to parse JSON. Essentially JSON
data needs to be in a particular structure or it doesn't make sense
to a JsonML builder.
Now that being said, the risk of opening this Pandora's Box is that
every developer and their mom might begin creating MIME types for
every piece of ad hoc JSON data. Granted if we went with #3, we
could just rely on IANA to police the JSON MIME type horizon. As it
is, in order to officially have a "application/XXXX+json" MIME, you
have to have a formalized standard and they have to accept your
application. See [ http://www.iana.org/assignments/media-types/ ]
for more info.
My only real fear is that if we don't pick a standard of some kind
then we run into the issues where incompatibility makes the feature
it was later better standardized (see RFC-4329) but this caused
confusion and incompatibility for years.
My suggestion would be option #3 with IANA policing the
official "application/XXXX+json" MIME space, but also some standard
set in place for "X-" MIME types. For instance a JsonML MIME type
isn't official, so technically it should be
"x-application/jsonml+json" rather than "application/jsonml+json".
This is the official way of "experimentally" creating a MIME type.
I hope this makes sense and that we can come to some sort of
--- In email@example.com, "kriszyp" wrote:
> I wanted to see if there was any prevailing consensus on if and how
> JSON subsets and alternatives should be denoted with MIME types.
> are a growing number of JSON subsets like JSON-RPC, JSONT, JsonML,
> JSON Schema, etc. There may be benefits in being able to define
> subset is begin used as a MIME type. XML has used a subtype+xml
> convention, and I noticed that Stephen McKamey is using this
> to suggest denoting JsonML as "application/jsonml+json". I am
> perfectly fine with using this convention, I just wanted to see if
> others felt this was the way to go, or if it is preferable to do
> "minor" subtyping that would not suggest a need for IANA
> like "application/json; rpc", or something like that.
> I am also curious if there any thoughts about JSON supersets. There
> have been little efforts to create any formal proposals in this
> but I don't think it is totally uncommon to use additional
> constructs for JSON-esque data, and postel's law application to JSON
> flexibility (non-quoted keys, comments, etc). One could think of
> libraries that don't do validation before an eval (Dojo and many
> (like json.org's library) would be only JSON acceptors. I am
> if MIME type definition might be valuable here as well (providers
> would know if they can include comments, for example).
> Anyway, I am not really making any proposals, just curious it there
> are prevailing feelings towards MIME types for defining different
- << Previous post in topic Next post in topic >>