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

Re: MIME types

Expand Messages
  • 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 1 of 9 , May 6, 2008
    View Source
    • 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 2 of 9 , May 6, 2008
      View Source
      • 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 3 of 9 , May 6, 2008
        View Source
        • 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 4 of 9 , May 6, 2008
          View Source
          • 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.