Bug 619

Summary:	Patch to add many sub-class-of definitions
Product:	shared-mime-info	Reporter:	David Faure <faure>
Component:	freedesktop.org.xml	Assignee:	Jonathan Blandford <jrb>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	high
Version:	unspecified
Hardware:	Other
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:
Attachments:	patch Patch with just the subclasses

Description David Faure 2004-05-14 23:46:37 UTC

This patch adds many missing sub-class-of definitions, in particular for all 
text types that are subclasses of text/plain. 
Not all text/* types should be subclasses of text/plain. The logic is to do it 
only where users might want to end up with a text editor to edit them. So I 
added it to e.g. all "source code" mimetypes and README files etc., but not to 
vcard or vcalendar files, those are not really readable and much better handled 
by the appropriate programs. This rule isn't very easy to apply though (e.g. do 
people want to read/edit XSL/FO files by hand if no better editor is available? 
Hmm, probably). Maybe text/plain should also be added to  
 
This patch also merges the two msword types by making them aliases. 
Same thing for the two msexcel types and the two realaudio types. 
 
Is text/x-xmi a subclass of text/xml? 
text/x-xslt is one, right? 
Is there a relation between text/rdf and text/rss? 
 
What's text/directory text/enriched and text/rfc822-headers? Mimetypes which 
have just a name and a comment (no glob nor magic) don't seem very useful in 
fact - at least no file manager will ever end up using them. But of course they 
can be useful for drag-n-drop etc. I just wonder if text/directory was meant 
for (e.g. kde's) ".directory" files... 
 
Thanks.

Comment 1 David Faure 2004-05-14 23:48:16 UTC

Created attachment 286 [details] [review]
patch

Comment 2 Thomas Leonard 2004-07-09 03:12:39 UTC

XSLT is certainly XML. Don't know about XMI, but I expect so.
There are two versions of RSS. One is a subclass of RDF, the other isn't.
Looks like text/directory should indeed have a glob.

I'm not sure that the explicit subclassing of all the text types is necessary.
The spec already says that all text/* are text/plain. This is pretty much the
requirement for a type to be in the text/* group in the first place. Some plain
text formats are elsewhere, eg application/x-python, precisely because they
shouldn't be opened in a text editor by default.

While you might not agree with all such choices, having two mechanisms for this
is clearly wrong. I'd be perfectly happy to show a VCARD in a text editor, for
example.

I think that for all text files, opening them in a text editor is better than
refusing to open them at all. The more interesting question is whether they
should appear on the menu as possible actions, given that more suitable programs
exist. Eg, if I have an RDF editor and an XML editor, I might want them both
listed as options for an RDF file, but I might not want a text editor there. It
depends a lot on the users, though.

Comment 3 Thomas Leonard 2004-07-09 04:32:18 UTC

Created attachment 459 [details] [review]
Patch with just the subclasses

I've applied the parts of the patch that fix the duplicate types. Here's the
rest of the original patch.

Comment 4 Christophe Fergeau 2004-12-10 12:31:56 UTC

Committed to CVS.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.