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

MIME types: eager or lazy?

Expand Messages
  • Hugh Winkler
    Hi all, When you re passing representations around - let s say you have defined some XML dialects - should you err on the side of defining new MIME types for
    Message 1 of 4 , Jul 9, 2005
    • 0 Attachment

      Hi all,

       

      When you’re passing representations around – let’s say you have defined some XML dialects – should you err on the side of defining new MIME types for each dialect e.g. application/vnd.somebody.purchaseorder.v13+xml, or should you prefer to subsume them all in the most general type you can, e.g. application/xml?

       

      If you version your xml dialect backwards or forwards incompatibly, must you create a new MIME type for it?

       

      I fear MIME type pollution. I also fear lots of application level sniffing of types. If anyone’s got some experience or opinion on the matter, I’d appreciate hearing pros and cons.

       

      Hugh

       

      http://www.wellstorm.com/  Wellstorm WITSML Service Platform

      http://witsml.blogspot.com/ WITSML and the Web

      http://hughw.blogspot.com/ Messages not Models

       

       

       

    • Jeoff Wilks
      In my experience, we had a specific XML-based file type that, when downloaded by the user, needed to be opened in a specific application. Initially we tried
      Message 2 of 4 , Jul 10, 2005
      • 0 Attachment
        In my experience, we had a specific XML-based file type that, when downloaded by the user, needed to be opened in a specific application. Initially we tried giving the files a unique file extension but was a regular xml mime-type. If memory serves me correctly this worked okay in Mozilla. But in spite of the unique extension Internet Explorer saw it as a regular XML document and displayed onscreen the XML source tree instead of opening the application. In order to get the Windows file association to work right we did have to invent a new, specific mime type.

        It seems that in the absence of a specific content-type header, Internet Explorer "sniffs" the actual content to try to guess the mime-type. Only if it can't guess the mime-type does it look at the file extension. The explanation is here:
        http://msdn.microsoft.com/workshop/networking/moniker/overview/appendix_a.asp

        When it sees any type of XML, it assumes "I can display that myself" and shows the XML source tree onscreen. This is not always the desired behavior. A custom mime-type is required in order to override that behavior.


        On 7/9/05, Hugh Winkler <hughw@...> wrote:

        Hi all,

         

        When you're passing representations around – let's say you have defined some XML dialects – should you err on the side of defining new MIME types for each dialect e.g. application/vnd.somebody.purchaseorder.v13+xml, or should you prefer to subsume them all in the most general type you can, e.g. application/xml?

         

        If you version your xml dialect backwards or forwards incompatibly, must you create a new MIME type for it?

         

        I fear MIME type pollution. I also fear lots of application level sniffing of types. If anyone's got some experience or opinion on the matter, I'd appreciate hearing pros and cons.

         

        Hugh

         

        http:// www.wellstorm.com/  Wellstorm WITSML Service Platform

        http://witsml.blogspot.com/WITSML and the Web

        http://hughw.blogspot.com/Messages not Models

         

         

         



        YAHOO! GROUPS LINKS




      • S. Mike Dierken
        Hmmm. There have been long and noisy discussion about how user agents should handle content with a specified content-type. Some developers want the client
        Message 3 of 4 , Jul 10, 2005
        • 0 Attachment
          Hmmm. There have been long and noisy discussion about how user agents should handle content with a specified content-type. Some developers want the client application to guess ('sniffing'), while others want the client app to follow the intent of the application author (dispatch on content-type only). There are problems on both sides - mainly that some application authors don't have control over how the server sets the content-type (XML comes out as text/plain, etc.) and that application authors don't have great control over dispatching XML-based content.0
           
          A long time ago I suggested that a general XML dispatcher component (plug-in, extension, COM-object, whatever) be built and have it consume two formats - 'application/xml' and 'application/content-disposition'. The second format would be an XML document that associates rules for routing XML documents to consuming applications. This was when RSS and client feed readers were starting to get popular - I thought that a site could have links to the 'config' that would map their flavor of RSS to the users preferred client application.
           
          PS
          In general, XML should not use text/xml, but application/xml - i've seen some applications (like the wicked cool backpackit.com site) use text/xml for remote application automation.
           
           
          ----- Original Message -----
          Sent: Sunday, July 10, 2005 5:33 AM
          Subject: Re: [rest-discuss] MIME types: eager or lazy?

          In my experience, we had a specific XML-based file type that, when downloaded by the user, needed to be opened in a specific application. Initially we tried giving the files a unique file extension but was a regular xml mime-type. If memory serves me correctly this worked okay in Mozilla. But in spite of the unique extension Internet Explorer saw it as a regular XML document and displayed onscreen the XML source tree instead of opening the application. In order to get the Windows file association to work right we did have to invent a new, specific mime type.

          It seems that in the absence of a specific content-type header, Internet Explorer "sniffs" the actual content to try to guess the mime-type. Only if it can't guess the mime-type does it look at the file extension. The explanation is here:
          http://msdn.microsoft.com/workshop/networking/moniker/overview/appendix_a.asp

          When it sees any type of XML, it assumes "I can display that myself" and shows the XML source tree onscreen. This is not always the desired behavior. A custom mime-type is required in order to override that behavior.


          On 7/9/05, Hugh Winkler <hughw@...> wrote:

          Hi all,

           

          When you're passing representations around – let's say you have defined some XML dialects – should you err on the side of defining new MIME types for each dialect e.g. application/vnd.somebody.purchaseorder.v13+xml, or should you prefer to subsume them all in the most general type you can, e.g. application/xml?

           

          If you version your xml dialect backwards or forwards incompatibly, must you create a new MIME type for it?

           

          I fear MIME type pollution. I also fear lots of application level sniffing of types. If anyone's got some experience or opinion on the matter, I'd appreciate hearing pros and cons.

           

          Hugh

           

          http:// www.wellstorm.com/  Wellstorm WITSML Service Platform

          http://witsml.blogspot.com/ WITSML and the Web

          http://hughw.blogspot.com/ Messages not Models

           

           

           



          YAHOO! GROUPS LINKS




        • Mark Baker
          ... A new media type is the only way to maintain self-descriptive messages. ... Probably a good idea. Better would be don t do that . 8-) ... The issue is
          Message 4 of 4 , Jul 11, 2005
          • 0 Attachment
            On Sat, Jul 09, 2005 at 10:54:58PM -0500, Hugh Winkler wrote:
            > Hi all,
            >
            >
            >
            > When you're passing representations around - let's say you have defined some
            > XML dialects - should you err on the side of defining new MIME types for
            > each dialect e.g. application/vnd.somebody.purchaseorder.v13+xml, or should
            > you prefer to subsume them all in the most general type you can, e.g.
            > application/xml?

            A new media type is the only way to maintain self-descriptive messages.

            > If you version your xml dialect backwards or forwards incompatibly, must you
            > create a new MIME type for it?

            Probably a good idea. Better would be "don't do that". 8-)

            > I fear MIME type pollution. I also fear lots of application level sniffing
            > of types. If anyone's got some experience or opinion on the matter, I'd
            > appreciate hearing pros and cons.

            The issue is that XML by itself doesn't provide a sufficiently rich
            framework that would allow one to solve the "media type explosion"
            problem. RDF/XML is one such "better XML" which attempts to solve that
            problem, but lots of folks don't like the tradeoffs it seems. The work
            we're doing in the W3C Compound Document Formats WG is another stab at
            doing a similar thing.

            Unfortunately, content sniffing (and assuming the root XML namespace
            replaces the need for a media type) for XML for the generic XML media
            types is pretty much pervasive, at least in browsers[1]. A lot of XML
            content also uses the generic types, from what I've seen, though lots
            of "+xml" media types are being registered which is good.

            [1] http://www.markbaker.ca/2004/01/XmlDispatchTest/

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