Raphael Bosshard <[EMAIL PROTECTED]> forwarded a message on Mon, 07 Jan 2002 20:09:17 +0100, it was originally from Daniel Veillard <[EMAIL PROTECTED]> on Mon, 7 Jan 2002 12:24:14 -0500, and addressed to the Gnome 2.0 list: > Yep, IMHO Mime-Type are slowing falling into obsolescence due to > composition and the fact that it's such a f...g pain to update that > registry that some new format tend to not even bother.
I wonder if he's talking about the W3C official registry or some software registry. It isn't that hard to add new MIME types to the BeOS's system (usually under the vendor specific groups). But yes, some objects are documents that contain many other things. Perhaps call them text/xml/document? Then your favorite XML composite viewer could open them up and load appropriate viewers for subobjects which do have a more specific MIME type. > The goal of the Mime-Type was to associate processing tool with > resources. Unfortuantely it's a too limited view to cope with most > of the complex formats. A better approach is a list/hierarchy of > strings and not a single one, the list of namespaces name of > a XML document, the list of mimetypes of a zip. To take the example > of a ZIP format it could be: > > (zip (image/gif, xml/docbook, image/gif)) > > to use a LISP like syntax. For a compound compressed XML document > > (gzip (application/xml (http://www.w3.org/2001/svg http://www.w3.org/))) > > I'm pretty sure you can find examples even outside of the XML world. > don't limit yourself to known-to-getting-obsolete mechanism when defining > new interfaces. Heh. Looks like a directory listing of the object system hierarchy, but with the types rather than the object names. But would that be useful for any real world purpose? If you have indexing working, you can find sub-objects of specified types (and other classifications) even if they are inside bigger objects. No need for overly descriptive MIME composites, unless you want them, and then they'd be easy to do. - Alex
