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

Re: [json] MIME types

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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.