Shared MIME-Info 0.12

[David Faure]

On Friday 29 August 2003 15:25, Thomas Leonard wrote:
> On Fri, Aug 29, 2003 at 02:32:05PM +0200, David Faure wrote:
> [...]
> > (except that we currently lack a few features like magic overriding
> > extensions for some mimetypes).
> 
> I've added the missing text to the recommended checking order:

Ooops, misunderstanding. I meant in KDE. 
I thought this was in the XDG spec already. Re-reading it, it appears that
priorities only apply to magic entries, not to pattern-matching.
OK, so your suggested addition will fix this:
> 	"If no explicit type is present, magic rules with a priority of 80
> 	or more should be tried next. These rules have a very low
> 	false-positive rate."

Great.

> I think some method to handle deprecated type names is the main missing
> feature. Something like:
> 
>       <mime-type type='audio/x-midi'>
> 	<type-renamed new_name='audio/midi'/>
>       </mime-type>
> 
> If noone suggests better names, I'll add it...

Yes, this is needed indeed. A more generic version of this would be to talk about
aliases. For instance application/x-tgz and application/x-targz are the same thing, etc.
The reason why we need aliases (and not just "only one mimetype for this in the spec"),
is that we always have to cope with mimetypes coming from the outside world:
for instance an HTTP server might send application/x-targz, when we only know about
the other one. At the moment we (in KDE) do the "conversion to a known mimetype"
for quite a few mimetypes, in the HTTP reader module, but this is awful, obviously :)
The main difference I see is a naming difference - renamed means "it was that way
before", whereas alias means "also understand this one". Of course code that
identifies the mimetype of a given file using the XDG spec would never return 
the alias, only the real mimetype name.

So that's for aliases. But the last thing I miss in the spec is mimetype inheritance.
I have already presented examples of that:
- many mimetypes are actually specializations of text/plain
- 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)

The idea (when we work on the mime->application association spec later) would be 
that more specialized viewers are preferred over more generic viewers, by default.

Now, if you agree with inheritance, the question becomes whether we can use it
for aliases (renamings and outside-world-mimetypes). I think for clarity it would
be better to have the two features independently, since aliases are purely
equivalent, inherited mimetypes are not.

-- 
David FAURE, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).