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

Re: [rest-discuss] Media type derivation: standardize the + semantics?

Expand Messages
  • Mike Kelly
    This seems like a big ask from the web ecosystem with very little practical upside. What s the point? Cheers, Mike ... with new implementations (a la
    Message 1 of 9 , Aug 12, 2011
    • 0 Attachment
      This seems like a big ask from the web ecosystem with very little practical upside.

      What's the point?

      Cheers,
      Mike

      On Friday, August 12, 2011, Sebastien Lambla <seb@...> wrote:
      > That is absolutely true, but then again old implementations can co-exist with new implementations (a la SetCookie2), as the new behavior couldn't possibly work with the old behavior.
      >
      > Say I had:
      > Content-Type: application/xhtml+xml
      > Content-Type2: application/xml/xhtml/rdf
      >
      > With a bit of conneg, the most resembling Content-Type can be returned, alongside an extended media type.
      >
      > An alternative is to use another character, a la application/rdf+xhtml+xml, or use the . notation, application/xml.xhtml.rdf, or even add a random media type attribute with the extended information.
      >
      >
      > ________________________________________
      > From: rest-discuss@yahoogroups.com [rest-discuss@yahoogroups.com] on behalf of Jakob Strauch [jakob.strauch@...]
      > Sent: 12 August 2011 07:29
      > To: rest-discuss@yahoogroups.com
      > Subject: [rest-discuss] Re: Media type derivation: standardize the + semantics?
      >
      >> I'd personally love to see standardisation around hierarchical identifiers instead of the +, by having application/xml/atom or even application/xml/html/rdf
      >
      > This would not be backwards compatible...
      >
      >
      >
      >
      >>
      >> Any processor could simply go up the tree to know what to do until they fall back on rules for the root media type (here, application, which by definition is to be treated as octet-stream).
      >>
      >> -----Original Message-----
      >> From: rest-discuss@yahoogroups.com [mailto:rest-discuss@yahoogroups.com] On Behalf Of Jakob Strauch
      >> Sent: 10 August 2011 14:34
      >> To: rest-discuss@yahoogroups.com
      >> Subject: [rest-discuss] Re: Media type derivation: standardize the + semantics?
      >>
      >> jason_h_erickson wrote:
      >>
      >> >> I like it.  The only concern is or backwards compatibility.  Say I have a resource representation that is not following the convention because I didn't really understand the convention or didn't follow it the way it will be interpreted.  For example, take the media type discussed in the previous post  that you mention, text/form+html.  Hypothetically, if I am producing that as a media type but really what I am sending is a snippet that is not a valid HTML document, is there any reason to fear that anything would stop working if proxies started interpreting that media type to expect valid HTML? <<
      >>
      >> This situation would be the same as not adhering to any other media type, i think. In fact your snippet would not even be a valid representation of the "derived" media type.
      >>
      >> I think, the only contraint would be, that e.g. a VALID "application/atom+xml" representation is still a valid "application/xml" representation. As far as i know, this is anyway state of the art. it is just not standardized (except for XML Media types [1]).
      >>
      >> The backward compatibilty is also given for intermediaries: if they do know the derivation concept, the visibility increases. if they do not know the correlation, they would handle such a media type as an unknown media type. like an intermediary today, who knows xml but not atom, would ignore atom documents.
      >>
      >> [1] http://www.ietf.org/rfc/rfc3023.txt
      >>
      >> --- In rest-discuss@yahoogroups.com, "Jakob Strauch" <jakob.strauch@> wrote:
      >> >
      >> > Due to previous posts [1] i was asking myself, if it would make sense to standarize the usage of the + sign in media type indications.
      >> >
      >> > I think the benfit would be, that a more specific media type like  "application/odata+atom+xml" (which is currently not existing) could be at least interpret as "application/atom+xml" (which is currently the media type of an odata resource [2]).
      >> >
      >> > An intermediary could look at the media type "application/odata+atom+xml" and could interpret it as a known atom representation, even if he don´t know the odata media type. If atom is also unknown, maybe he is interessted, that it´s a valid xml document, too.
      >> >
      >> > This seems to be just an convention at the moment or standarized only for xml-based documents [3]. Furthermore, it would imho calm down the debate about generic vs specific media type.
      >> >
      >> > What do you think?
      >> >
      >> > [1] http://tech.groups.yahoo.com/group/rest-discuss/message/17665
      >> > [2] http://www.odata.org/developers/protocols/atom-format
      >> > [3] http://www.ietf.org/rfc/rfc3023.txt
      >> >
      >>
      >>
      >>
      >>
      >> ------------------------------------
      >>
      >> Yahoo! Groups Links
      >>
      >
      >
      >
      >
      > ------------------------------------
      >
      > Yahoo! Groups Links
      >
      >
      >
      >
      >
      > ------------------------------------
      >
      > Yahoo! Groups Links
      >
      > <*
    • Jakob Strauch
      I agree in the case of Sebastiens proposal. All i´m proposing, is to standardize something, that is already a (in some cases an unwritten) convention. I think
      Message 2 of 9 , Aug 13, 2011
      • 0 Attachment
        I agree in the case of Sebastiens proposal. All i´m proposing, is to standardize something, that is already a (in some cases an unwritten) convention.

        I think it would improve extensibility and visibility on the web: I can introduce new media types based on existing ones. Any client, e.g. a browser, being aware of the "hierachical media type" concept could render a "application/contact+xhtml+xml" as usual (if he has no clue what contact+html is) or could do something useful with it. For example, providing the user a popup with "Do you want to add this contact to your address book?".

        Conneg and user agent header would also enable backward compatibility by sending "just application/xhtml+xml".

        Am i missing something? I feel, that would have a great impact on web interaction...


        --- In rest-discuss@yahoogroups.com, Mike Kelly <mike@...> wrote:
        >
        > This seems like a big ask from the web ecosystem with very little practical
        > upside.
        >
        > What's the point?
        >
        > Cheers,
        > Mike
        >
        > On Friday, August 12, 2011, Sebastien Lambla <seb@...> wrote:
        > > That is absolutely true, but then again old implementations can co-exist
        > with new implementations (a la SetCookie2), as the new behavior couldn't
        > possibly work with the old behavior.
        > >
        > > Say I had:
        > > Content-Type: application/xhtml+xml
        > > Content-Type2: application/xml/xhtml/rdf
        > >
        > > With a bit of conneg, the most resembling Content-Type can be returned,
        > alongside an extended media type.
        > >
        > > An alternative is to use another character, a la
        > application/rdf+xhtml+xml, or use the . notation, application/xml.xhtml.rdf,
        > or even add a random media type attribute with the extended information.
        > >
        > >
        > > ________________________________________
        > > From: rest-discuss@yahoogroups.com [rest-discuss@yahoogroups.com] on
        > behalf of Jakob Strauch [jakob.strauch@...]
        > > Sent: 12 August 2011 07:29
        > > To: rest-discuss@yahoogroups.com
        > > Subject: [rest-discuss] Re: Media type derivation: standardize the +
        > semantics?
        > >
        > >> I'd personally love to see standardisation around hierarchical
        > identifiers instead of the +, by having application/xml/atom or even
        > application/xml/html/rdf
        > >
        > > This would not be backwards compatible...
        > >
        > >
        > >
        > >
        > >>
        > >> Any processor could simply go up the tree to know what to do until they
        > fall back on rules for the root media type (here, application, which by
        > definition is to be treated as octet-stream).
        > >>
        > >> -----Original Message-----
        > >> From: rest-discuss@yahoogroups.com [mailto:rest-discuss@yahoogroups.com]
        > On Behalf Of Jakob Strauch
        > >> Sent: 10 August 2011 14:34
        > >> To: rest-discuss@yahoogroups.com
        > >> Subject: [rest-discuss] Re: Media type derivation: standardize the +
        > semantics?
        > >>
        > >> jason_h_erickson wrote:
        > >>
        > >> >> I like it. The only concern is or backwards compatibility. Say I
        > have a resource representation that is not following the convention because
        > I didn't really understand the convention or didn't follow it the way it
        > will be interpreted. For example, take the media type discussed in the
        > previous post that you mention, text/form+html. Hypothetically, if I am
        > producing that as a media type but really what I am sending is a snippet
        > that is not a valid HTML document, is there any reason to fear that anything
        > would stop working if proxies started interpreting that media type to expect
        > valid HTML? <<
        > >>
        > >> This situation would be the same as not adhering to any other media type,
        > i think. In fact your snippet would not even be a valid representation of
        > the "derived" media type.
        > >>
        > >> I think, the only contraint would be, that e.g. a VALID
        > "application/atom+xml" representation is still a valid "application/xml"
        > representation. As far as i know, this is anyway state of the art. it is
        > just not standardized (except for XML Media types [1]).
        > >>
        > >> The backward compatibilty is also given for intermediaries: if they do
        > know the derivation concept, the visibility increases. if they do not know
        > the correlation, they would handle such a media type as an unknown media
        > type. like an intermediary today, who knows xml but not atom, would ignore
        > atom documents.
        > >>
        > >> [1] http://www.ietf.org/rfc/rfc3023.txt
        > >>
        > >> --- In rest-discuss@yahoogroups.com, "Jakob Strauch" <jakob.strauch@>
        > wrote:
        > >> >
        > >> > Due to previous posts [1] i was asking myself, if it would make sense
        > to standarize the usage of the + sign in media type indications.
        > >> >
        > >> > I think the benfit would be, that a more specific media type like
        > "application/odata+atom+xml" (which is currently not existing) could be at
        > least interpret as "application/atom+xml" (which is currently the media type
        > of an odata resource [2]).
        > >> >
        > >> > An intermediary could look at the media type
        > "application/odata+atom+xml" and could interpret it as a known atom
        > representation, even if he don´t know the odata media type. If atom is also
        > unknown, maybe he is interessted, that it´s a valid xml document, too.
        > >> >
        > >> > This seems to be just an convention at the moment or standarized only
        > for xml-based documents [3]. Furthermore, it would imho calm down the debate
        > about generic vs specific media type.
        > >> >
        > >> > What do you think?
        > >> >
        > >> > [1] http://tech.groups.yahoo.com/group/rest-discuss/message/17665
        > >> > [2] http://www.odata.org/developers/protocols/atom-format
        > >> > [3] http://www.ietf.org/rfc/rfc3023.txt
        > >> >
        > >>
        > >>
        > >>
        > >>
        > >> ------------------------------------
        > >>
        > >> Yahoo! Groups Links
        > >>
        > >
        > >
        > >
        > >
        > > ------------------------------------
        > >
        > > Yahoo! Groups Links
        > >
        > >
        > >
        > >
        > >
        > > ------------------------------------
        > >
        > > Yahoo! Groups Links
        > >
        > > <*
        >
      • Mike Kelly
        ... You can already base a media type on an existing one by documenting that in it s specification ... You don t need a media type identifier to do this, you
        Message 3 of 9 , Aug 13, 2011
        • 0 Attachment
          On Sat, Aug 13, 2011 at 3:20 PM, Jakob Strauch <jakob.strauch@...> wrote:
          I agree in the case of Sebastiens proposal. All i´m proposing, is to standardize something, that is already a (in some cases an unwritten) convention.

          I think it would improve extensibility and visibility on the web: I can introduce new media types based on existing ones.

          You can already base a media type on an existing one by documenting that in it's specification 
           
          Any client, e.g. a browser, being aware of the "hierachical media type" concept could render a "application/contact+xhtml+xml" as usual (if he has no clue what contact+html is) or could do something useful with it. For example, providing the user a popup with "Do you want to add this contact to your address book?".

          You don't need a media type identifier to do this, you should do it by standardising a link relation e.g. rel="contact"

          Cheers,
          Mike
        • Sebastien Lambla
          Mike, The point I was trying to make, which I already made at unconf last year, is about genericity of processing of a media type. I ll re-explain what I mean
          Message 4 of 9 , Aug 15, 2011
          • 0 Attachment
             Mike,

            The point I was trying to make, which I already made at unconf last year, is about genericity of processing of a media type. I'll re-explain what I mean by it here, not for you as I know you know, and presume you disagree, with most things I say.

            The minting of a new media type is done to mark the entity body as having semantics that cannot be processed from knowing how to process the base media type. For example, an atom feed cannot be processed as an atom feed without knowing the atom spec, and processing it in XML will not be useful for many users (relative to the size of the internet).

            On the other hand, if the additional data is added inline with little additional processing needed to understand its structure, then you already have to open the message to do something useful with it and no additional knowledge is needed (from the client perspective) to make something useful out of it. Microdata, profile and things like images to encode information are all in that category.

            So it's all black or white, leaving little choice for a better "fallback". The +xml convention is not implemneted by anyone I'm aware of to fall-back on xml processing, and even if it was, that's one level, not more. Having the possibility of specializing media types (appllication/xml/atom/vnd.contacts) would enable a *certain* level of flexibility to allow the user-agent to revert to something else, and provide more flexibility in customizing existing media types while still tagging the existance of the flexibility.

            Note that the interesting discussion relly can be about compound media types, where multiple media types coexist in the same document, or custom media types that contain standardized ones (for example a custom xml type containing fragments of xhtml 1.1). That conversation has been had with no nice outcome

            <nitpicker corner>
            If you can't understand why the extended media type syntax is useful but you think +xml is nifty, there is no logic left for you to reply to this email. :)
            </nitpicker corner>


            From: rest-discuss@yahoogroups.com [rest-discuss@yahoogroups.com] on behalf of Mike Kelly [mike@...]
            Sent: 13 August 2011 17:30
            To: Jakob Strauch
            Cc: rest-discuss@yahoogroups.com
            Subject: Re: [rest-discuss] Re: Media type derivation: standardize the + semantics?





            On Sat, Aug 13, 2011 at 3:20 PM, Jakob Strauch <jakob.strauch@...> wrote:
            I agree in the case of Sebastiens proposal. All i´m proposing, is to standardize something, that is already a (in some cases an unwritten) convention.

            I think it would improve extensibility and visibility on the web: I can introduce new media types based on existing ones.

            You can already base a media type on an existing one by documenting that in it's specification 
             
            Any client, e.g. a browser, being aware of the "hierachical media type" concept could render a "application/contact+xhtml+xml" as usual (if he has no clue what contact+html is) or could do something useful with it. For example, providing the user a popup with "Do you want to add this contact to your address book?".

            You don't need a media type identifier to do this, you should do it by standardising a link relation e.g. rel="contact"

            Cheers,
            Mike


          Your message has been successfully submitted and would be delivered to recipients shortly.