MIME subclasses

[Jonathan Blandford]

David Faure <dfaure at trolltech.com> writes:

> As I said previously: mimetype inheritance is needed, with a much more 
> flexible model than "image/gif is an image".

Right.  mime-types are inherently inflexible, and we all spend a lot of
time and energy dealing with their shortcomings.  It sucks, but is the
universe of categorization that we're handed.[1]
> Examples:
> - many mimetypes are actually specializations of text/plain
>  (and not all are called text/*. For instance application/x-perl etc.)
> 
> - OpenOffice files and KOffice files are specializations of application/x-zip
> (this allows to offer a zip utility for office documents)
>
> - (implicitely) all mimetypes except inode/* are specializations of application/octet-stream
> (saying this allows to bind them all to an hex editor at the bottom of the offers list)
> 
> - text/xml is a specialization of SGML (if sgml tools apply to xml)
> - text/docbook is a specialization of XML (yes, I know that text/docbook is not the
> standard name, but you get the idea)
> etc. etc.

My problem with this isn't the fact that we need a way to see multiple
facets of a file, but it's that we're applying the inheritance to the
type.  Perhaps a system where we returned a multiple mime-types
depending on what attributes the file has makes more sense.  As a
counter example to the ones you gave:

- gnumeric files can be optionally zipped up.  That means that in one
  case, the file could inherit from text/xml and text/plain, and in the
  other it could inherit from application/x-zip.  Encoding this in the
  mime-type doesn't make sense unless we hyper-specialize
  (application/x-gnumeric and application/x-gnumeric-zipped).  In this
  case, it's a totally artificial construct, and won't really scale for
  other attributes a particular file might have (such as encryption).

> I'm sorry, but if the XDG spec doesn't allow KDE to model mimetype inheritance,
> I don't see how KDE could switch to it at some point. This is something we
> already model and use, so we definitely need it in whichever replacement we
> adopt. If other apps/environments ignore the inheritance, it shouldn't be a big
> problem.

Do you use inheritance right now in KDE?  Perhaps it would be useful to
see what your inheritance tree looks like.

> This being said, I'm not a bit surprised by the RDF idea - but I know little
> about RDF.

Me too. (-:  I'm willing to defer to anyone with more RDF knowledge or
experience here.

Thanks,
-Jonathan

[1] Unless we want to ditch all mime altogether and come up with a
system more appropriate for the desktop