Loading ...
Sorry, an error occurred while loading the content.

MIME types

Expand Messages
  • kriszyp
    I wanted to see if there was any prevailing consensus on if and how JSON subsets and alternatives should be denoted with MIME types. There are a growing number
    Message 1 of 9 , May 5, 2008
    • 0 Attachment
      I wanted to see if there was any prevailing consensus on if and how
      JSON subsets and alternatives should be denoted with MIME types. There
      are a growing number of JSON subsets like JSON-RPC, JSONT, JsonML,
      JSON Schema, etc. There may be benefits in being able to define which
      subset is begin used as a MIME type. XML has used a subtype+xml
      convention, and I noticed that Stephen McKamey is using this precedent
      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 more
      "minor" subtyping that would not suggest a need for IANA registration
      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 area,
      but I don't think it is totally uncommon to use additional JavaScript
      constructs for JSON-esque data, and postel's law application to JSON
      almost invariably means allowing for additional JavaScript defined
      flexibility (non-quoted keys, comments, etc). One could think of
      JavaScript expressions as a type unto themselves, the true superset of
      JSON (JavaScript itself is not actually a correct superset of JSON
      because JSON is not valid JavaScript by itself, it must be enclosed in
      paranthesis to make it a JavaScript expression). Generally JavaScript
      libraries that don't do validation before an eval (Dojo and many
      others) are actually full JavaScript expression acceptors, and
      non-JavaScript libraries and JavaScript libraries that do validation
      (like json.org's library) would be only JSON acceptors. I am wondering
      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 JSON
      formats.

      Thanks,
      Kris
    • Tatu Saloranta
      ... I think one big practical problem is that there doesn t seem to be a way to gracefully handle the problem of auto-detecting superset in use. That is, plain
      Message 2 of 9 , May 5, 2008
      • 0 Attachment
        On Mon, May 5, 2008 at 7:31 AM, kriszyp <kriszyp@...> wrote:

        > I am also curious if there any thoughts about JSON supersets. There
        > have been little efforts to create any formal proposals in this area,
        > but I don't think it is totally uncommon to use additional JavaScript
        > constructs for JSON-esque data, and postel's law application to JSON
        > almost invariably means allowing for additional JavaScript defined
        > flexibility (non-quoted keys, comments, etc). One could think of

        I think one big practical problem is that there doesn't seem to be a
        way to gracefully handle the problem of auto-detecting superset in
        use. That is, plain old JSON unfortunately has no place (similar to,
        say, xml declaration) to add something to allow processors to figure
        out if it's "plain" json or something else.
        While lack of such marker makes it easier to embed json (json
        encapsulation in json is trivial; in xml declaration & single-root
        requirement make it very cumbersome to embed xml in xml) it's a pain
        if one tries to extend markup itself.
        That's why I suspect it might be best that json remained as is, and
        further development was done at higher level by using what exists,
        instead of trying to shoehorn new features at low level ("just because
        something can be done don't mean it should").
        But then again, if it was accepted that things didn't remain backwards
        compatible, some features would be easy to add: things like comments
        (which I miss -- there's no way for generators to add notes as to
        sources, or time of generation), and have general usefulness.

        Anyway: my one comment regarding supersets is that any extensions to
        JSON itself should not be javascript-oriented.
        I really want "core" Json to remain language-agnostics (and become one
        in developers' minds); and if there are extensions that are more
        js-oriented, those be strict supersets which can be reliably detected,
        so that apps and systems that are not javascript-based can either
        ignore them, or downgrade processing suitably.

        -+ Tatu +-
      • Michal Migurski
        ... +1, keep it simple. Most of my JSON use is as a communication format between JS, Python, PHP, etc. There s no value here to having JS-specific features in
        Message 3 of 9 , May 5, 2008
        • 0 Attachment
          > While lack of such marker makes it easier to embed json (json
          > encapsulation in json is trivial; in xml declaration & single-root
          > requirement make it very cumbersome to embed xml in xml) it's a pain
          > if one tries to extend markup itself.
          > That's why I suspect it might be best that json remained as is, and
          > further development was done at higher level by using what exists,
          > instead of trying to shoehorn new features at low level ("just because
          > something can be done don't mean it should").
          >

          +1, keep it simple.

          Most of my JSON use is as a communication format between JS, Python,
          PHP, etc. There's no value here to having JS-specific features in the
          format.

          -mike.

          ----------------------------------------------------------------
          michal migurski- mike@...
          415.558.1610
        • Kris Zyp
          Perhaps I wasn t clear, I wasn t intending to propose that anyone needs to adopt a superset of JSON or add any features to JSON. I was simply asking how and if
          Message 4 of 9 , May 5, 2008
          • 0 Attachment
            Perhaps I wasn't clear, I wasn't intending to propose that anyone needs to adopt a superset of JSON or add any features to JSON. I was simply asking how and if people like to define JSON variants (most importantly subsets) with MIME types. Sorry for the superset digression...
            Kris

            ----- Original Message -----
            From: Michal Migurski
            To: json@yahoogroups.com
            Sent: Monday, May 05, 2008 11:12 AM
            Subject: Re: [json] MIME types


            > While lack of such marker makes it easier to embed json (json
            > encapsulation in json is trivial; in xml declaration & single-root
            > requirement make it very cumbersome to embed xml in xml) it's a pain
            > if one tries to extend markup itself.
            > That's why I suspect it might be best that json remained as is, and
            > further development was done at higher level by using what exists,
            > instead of trying to shoehorn new features at low level ("just because
            > something can be done don't mean it should").
            >

            +1, keep it simple.

            Most of my JSON use is as a communication format between JS, Python,
            PHP, etc. There's no value here to having JS-specific features in the
            format.

            -mike.

            ----------------------------------------------------------
            michal migurski- mike@...
            415.558.1610





            [Non-text portions of this message have been removed]
          • Nick Thompson
            I would like to see one additional mime type and associated file extension, something like text/envelope+json and .je - not important. This format would be a
            Message 5 of 9 , May 5, 2008
            • 0 Attachment
              I would like to see one additional mime type and associated file
              extension, something like text/envelope+json and ".je" - not important.
              This format would be a JSON document containing an object with a well
              defined container or envelope format, and of course as many subobjects
              as you want to put in there.

              Once you have this envelope it's easy to add new information to it that
              will be ignored by old processors, and you have the full expressiveness
              of JSON for all your metadata needs. I don't see why anybody would
              want to deal with new mime types for JSON if a standard envelope format
              were available.

              nick

              Kris Zyp wrote:
              >
              >
              > Perhaps I wasn't clear, I wasn't intending to propose that anyone needs
              > to adopt a superset of JSON or add any features to JSON. I was simply
              > asking how and if people like to define JSON variants (most importantly
              > subsets) with MIME types. Sorry for the superset digression...
              > Kris
              >
              > ----- Original Message -----
              > From: Michal Migurski
              > To: json@yahoogroups.com <mailto:json%40yahoogroups.com>
              > Sent: Monday, May 05, 2008 11:12 AM
              > Subject: Re: [json] MIME types
              >
              > > While lack of such marker makes it easier to embed json (json
              > > encapsulation in json is trivial; in xml declaration & single-root
              > > requirement make it very cumbersome to embed xml in xml) it's a pain
              > > if one tries to extend markup itself.
              > > That's why I suspect it might be best that json remained as is, and
              > > further development was done at higher level by using what exists,
              > > instead of trying to shoehorn new features at low level ("just because
              > > something can be done don't mean it should").
              > >
              >
              > +1, keep it simple.
              >
              > Most of my JSON use is as a communication format between JS, Python,
              > PHP, etc. There's no value here to having JS-specific features in the
              > format.
              >
              > -mike.
              >
              > ----------------------------------------------------------
              > michal migurski- mike@... <mailto:mike%40stamen.com>
              > 415.558.1610
              >
              > [Non-text portions of this message have been removed]
              >
              >
            • Stephen M. McKamey
              No 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
              Message 6 of 9 , May 6, 2008
              • 0 Attachment
                No 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
                camps:

                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
                useless. Initially JavaScript itself suffered from this issue until
                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
                consensus.

                smm

                --- In json@yahoogroups.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.
                There
                > are a growing number of JSON subsets like JSON-RPC, JSONT, JsonML,
                > JSON Schema, etc. There may be benefits in being able to define
                which
                > subset is begin used as a MIME type. XML has used a subtype+xml
                > convention, and I noticed that Stephen McKamey is using this
                precedent
                > 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
                more
                > "minor" subtyping that would not suggest a need for IANA
                registration
                > 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
                area,
                > but I don't think it is totally uncommon to use additional
                JavaScript
                > constructs for JSON-esque data, and postel's law application to JSON
                > almost invariably means allowing for additional JavaScript defined
                > flexibility (non-quoted keys, comments, etc). One could think of
                > JavaScript expressions as a type unto themselves, the true superset
                of
                > JSON (JavaScript itself is not actually a correct superset of JSON
                > because JSON is not valid JavaScript by itself, it must be enclosed
                in
                > paranthesis to make it a JavaScript expression). Generally
                JavaScript
                > libraries that don't do validation before an eval (Dojo and many
                > others) are actually full JavaScript expression acceptors, and
                > non-JavaScript libraries and JavaScript libraries that do validation
                > (like json.org's library) would be only JSON acceptors. I am
                wondering
                > 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
                JSON
                > formats.
                >
                > Thanks,
                > Kris
              • Kris Zyp
                Thank you Stephen, this exactly what I was asking! Thanks for clearly articulating this. I was also wondering if there is an option #4, which may be an
                Message 7 of 9 , May 6, 2008
                • 0 Attachment
                  Thank you Stephen, this exactly what I was asking! Thanks for clearly articulating this. I was also wondering if there is an option #4, which may be an enhancement of #1, where we also use application/json, but we include extra info after a semicolon to denote structure/application information. JsonML might be:
                  application/json; type=jsonml

                  Or something like that. I believe there other types that use something like this to include extra info; multipart includes boundary definition after a semicolon, and I have seen charset info included after a semicolon. However, I am not sure what the semantic intents and constraints are for this approach, it may be inappropriate to define subtypes in this manner. I really am fine with any of these approaches and just wanted to get some consensus. I am perfectly content to follow your (Stephen) precedent with {x-}application/subtype+json.

                  Thanks,
                  Kris


                  ----- Original Message -----
                  From: Stephen M. McKamey
                  To: json@yahoogroups.com
                  Sent: Tuesday, May 06, 2008 8:17 AM
                  Subject: [json] Re: MIME types


                  No 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
                  camps:

                  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
                  useless. Initially JavaScript itself suffered from this issue until
                  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
                  consensus.

                  smm

                  --- In json@yahoogroups.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.
                  There
                  > are a growing number of JSON subsets like JSON-RPC, JSONT, JsonML,
                  > JSON Schema, etc. There may be benefits in being able to define
                  which
                  > subset is begin used as a MIME type. XML has used a subtype+xml
                  > convention, and I noticed that Stephen McKamey is using this
                  precedent
                  > 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
                  more
                  > "minor" subtyping that would not suggest a need for IANA
                  registration
                  > 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
                  area,
                  > but I don't think it is totally uncommon to use additional
                  JavaScript
                  > constructs for JSON-esque data, and postel's law application to JSON
                  > almost invariably means allowing for additional JavaScript defined
                  > flexibility (non-quoted keys, comments, etc). One could think of
                  > JavaScript expressions as a type unto themselves, the true superset
                  of
                  > JSON (JavaScript itself is not actually a correct superset of JSON
                  > because JSON is not valid JavaScript by itself, it must be enclosed
                  in
                  > paranthesis to make it a JavaScript expression). Generally
                  JavaScript
                  > libraries that don't do validation before an eval (Dojo and many
                  > others) are actually full JavaScript expression acceptors, and
                  > non-JavaScript libraries and JavaScript libraries that do validation
                  > (like json.org's library) would be only JSON acceptors. I am
                  wondering
                  > 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
                  JSON
                  > formats.
                  >
                  > Thanks,
                  > Kris





                  [Non-text portions of this message have been removed]
                • Stephen M. McKamey
                  I would also support a #4 as you ve described as long as whatever it is works within the IANA restraints. It has been a while now since I sifted through the
                  Message 8 of 9 , May 6, 2008
                  • 0 Attachment
                    I would also support a #4 as you've described as long as whatever it
                    is works within the IANA restraints. It has been a while now since I
                    sifted through the RFCs but it might be a good time to revisit. The
                    commentary which influenced my initial stance was in the XML MIME
                    Type RFC:

                    http://tools.ietf.org/html/rfc3023#page-32

                    Definitely worth a read as they've justified the reasoning for XML's
                    usage of the "+xml" style. They also discuss some alternatives.

                    Thanks,
                    smm

                    --- In json@yahoogroups.com, "Kris Zyp" <kriszyp@...> wrote:
                    >
                    > Thank you Stephen, this exactly what I was asking! Thanks for
                    clearly articulating this. I was also wondering if there is an option
                    #4, which may be an enhancement of #1, where we also use
                    application/json, but we include extra info after a semicolon to
                    denote structure/application information. JsonML might be:
                    > application/json; type=jsonml
                    >
                    > Or something like that. I believe there other types that use
                    something like this to include extra info; multipart includes
                    boundary definition after a semicolon, and I have seen charset info
                    included after a semicolon. However, I am not sure what the semantic
                    intents and constraints are for this approach, it may be
                    inappropriate to define subtypes in this manner. I really am fine
                    with any of these approaches and just wanted to get some consensus. I
                    am perfectly content to follow your (Stephen) precedent with {x-}
                    application/subtype+json.
                    >
                    > Thanks,
                    > Kris
                    >
                    >
                    > ----- Original Message -----
                    > From: Stephen M. McKamey
                    > To: json@yahoogroups.com
                    > Sent: Tuesday, May 06, 2008 8:17 AM
                    > Subject: [json] Re: MIME types
                    >
                    >
                    > No 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
                    > camps:
                    >
                    > 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
                    > useless. Initially JavaScript itself suffered from this issue
                    until
                    > 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
                    > consensus.
                    >
                    > smm
                    >
                    > --- In json@yahoogroups.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.
                    > There
                    > > are a growing number of JSON subsets like JSON-RPC, JSONT,
                    JsonML,
                    > > JSON Schema, etc. There may be benefits in being able to define
                    > which
                    > > subset is begin used as a MIME type. XML has used a subtype+xml
                    > > convention, and I noticed that Stephen McKamey is using this
                    > precedent
                    > > 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
                    > more
                    > > "minor" subtyping that would not suggest a need for IANA
                    > registration
                    > > 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
                    > area,
                    > > but I don't think it is totally uncommon to use additional
                    > JavaScript
                    > > constructs for JSON-esque data, and postel's law application to
                    JSON
                    > > almost invariably means allowing for additional JavaScript
                    defined
                    > > flexibility (non-quoted keys, comments, etc). One could think of
                    > > JavaScript expressions as a type unto themselves, the true
                    superset
                    > of
                    > > JSON (JavaScript itself is not actually a correct superset of
                    JSON
                    > > because JSON is not valid JavaScript by itself, it must be
                    enclosed
                    > in
                    > > paranthesis to make it a JavaScript expression). Generally
                    > JavaScript
                    > > libraries that don't do validation before an eval (Dojo and many
                    > > others) are actually full JavaScript expression acceptors, and
                    > > non-JavaScript libraries and JavaScript libraries that do
                    validation
                    > > (like json.org's library) would be only JSON acceptors. I am
                    > wondering
                    > > 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
                    > JSON
                    > > formats.
                    > >
                    > > Thanks,
                    > > Kris
                  • Kris Zyp
                    Thank you, that RFC is very helpful, and they definitely make a strong case for option #3 instead of #4. One of the most important influences in the decision
                    Message 9 of 9 , May 6, 2008
                    • 0 Attachment
                      Thank you, that RFC is very helpful, and they definitely make a strong case for option #3 instead of #4. One of the most important influences in the decision is in how you want MIME dispatchers built on existing infrastructure to respond to different JSON types. If you think it would be best for all JSON content to be handled by one application which would then have different internal logic for different subtypes, you would may want some variant on option #4 (although there are additional complications with getting the additional info through in some cases), but if different applications should handle the different types in MIME dispatching infrastructures, we should probably use #3. This is kind of a difficult analysis to use since I believe most JSON applications probably don't even use MIME dispatching architectures (like XHR).

                      Anyway, based on that RFC I would be inclined to think option #3 (application/subtype+json) is probably the best bet for things like JSON-RPC, JsonML, JSON Schema, etc. There may be some situations where MIME parameters may be helpful in denoting extra features, for example using JSON referencing would probably be best defined as a MIME parameter (especially since it is applicable to multiple subtypes), and explicitly stating how dates are represented may be something to define in a MIME parameter as well.

                      Thanks,
                      Kris
                      ps
                      With great trepidation that I might spark another superset rabbit trail, it is also interesting to note the obvious parallel alternate syntax MIME types that correspond to these types. For example a browser might well say
                      Accept: x-application/jsonml+javascript-expr, x-application/jsonml+json
                      to indicate that it can accept more than just JSON (comments, dates, etc). However, I want even bother to ask if this seems reasonable lest others think I am suggesting that extra features be added to JSON :).


                      ----- Original Message -----
                      From: Stephen M. McKamey
                      To: json@yahoogroups.com
                      Sent: Tuesday, May 06, 2008 9:03 AM
                      Subject: [json] Re: MIME types


                      I would also support a #4 as you've described as long as whatever it
                      is works within the IANA restraints. It has been a while now since I
                      sifted through the RFCs but it might be a good time to revisit. The
                      commentary which influenced my initial stance was in the XML MIME
                      Type RFC:

                      http://tools.ietf.org/html/rfc3023#page-32

                      Definitely worth a read as they've justified the reasoning for XML's
                      usage of the "+xml" style. They also discuss some alternatives.

                      Thanks,
                      smm

                      --- In json@yahoogroups.com, "Kris Zyp" <kriszyp@...> wrote:
                      >
                      > Thank you Stephen, this exactly what I was asking! Thanks for
                      clearly articulating this. I was also wondering if there is an option
                      #4, which may be an enhancement of #1, where we also use
                      application/json, but we include extra info after a semicolon to
                      denote structure/application information. JsonML might be:
                      > application/json; type=jsonml
                      >
                      > Or something like that. I believe there other types that use
                      something like this to include extra info; multipart includes
                      boundary definition after a semicolon, and I have seen charset info
                      included after a semicolon. However, I am not sure what the semantic
                      intents and constraints are for this approach, it may be
                      inappropriate to define subtypes in this manner. I really am fine
                      with any of these approaches and just wanted to get some consensus. I
                      am perfectly content to follow your (Stephen) precedent with {x-}
                      application/subtype+json.
                      >
                      > Thanks,
                      > Kris
                      >
                      >
                      > ----- Original Message -----
                      > From: Stephen M. McKamey
                      > To: json@yahoogroups.com
                      > Sent: Tuesday, May 06, 2008 8:17 AM
                      > Subject: [json] Re: MIME types
                      >
                      >
                      > No 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
                      > camps:
                      >
                      > 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
                      > useless. Initially JavaScript itself suffered from this issue
                      until
                      > 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
                      > consensus.
                      >
                      > smm
                      >
                      > --- In json@yahoogroups.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.
                      > There
                      > > are a growing number of JSON subsets like JSON-RPC, JSONT,
                      JsonML,
                      > > JSON Schema, etc. There may be benefits in being able to define
                      > which
                      > > subset is begin used as a MIME type. XML has used a subtype+xml
                      > > convention, and I noticed that Stephen McKamey is using this
                      > precedent
                      > > 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
                      > more
                      > > "minor" subtyping that would not suggest a need for IANA
                      > registration
                      > > 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
                      > area,
                      > > but I don't think it is totally uncommon to use additional
                      > JavaScript
                      > > constructs for JSON-esque data, and postel's law application to
                      JSON
                      > > almost invariably means allowing for additional JavaScript
                      defined
                      > > flexibility (non-quoted keys, comments, etc). One could think of
                      > > JavaScript expressions as a type unto themselves, the true
                      superset
                      > of
                      > > JSON (JavaScript itself is not actually a correct superset of
                      JSON
                      > > because JSON is not valid JavaScript by itself, it must be
                      enclosed
                      > in
                      > > paranthesis to make it a JavaScript expression). Generally
                      > JavaScript
                      > > libraries that don't do validation before an eval (Dojo and many
                      > > others) are actually full JavaScript expression acceptors, and
                      > > non-JavaScript libraries and JavaScript libraries that do
                      validation
                      > > (like json.org's library) would be only JSON acceptors. I am
                      > wondering
                      > > 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
                      > JSON
                      > > formats.
                      > >
                      > > Thanks,
                      > > Kris





                      [Non-text portions of this message have been removed]
                    Your message has been successfully submitted and would be delivered to recipients shortly.