cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Myers <phan...@pirouline.sts.jhu.edu>
Subject Re: Mime-Types
Date Wed, 16 Jul 2003 19:58:06 GMT
I screwed up my argument by over complicating the example:

> > finder?  They use file extentions!!!
> 
> I think this is not the case.
Me too, but i was wrong.  It so uses file extensions.  It's so sad.  See below.

> 
> > OS9- had file attributes to store typing
> > information.
> 
> I believe this is true for OSX as well.
Again, I thought this was true until I proved to myself otherwise.

> 
> > That has it's advantages and disadvantages- Unix has this
> > perfectly wonderful system for typing, /usr/bin/file and /etc/magic.
> 
> hmmm, a matadata inference system is a good help against lazyness, but 
> it's never as effective as explicit metadata. IMHO, POSIX falls short 
> in that domain and UNIX just tried to work around it with automagic 
> type discovery (which <?xml version="1.0"?> shows it can be a massive 
> mistake!)
Fair enough, but my point is that apple moved away from explicit metadata.

> > Here's a fun exersize.

> If your download is on HTTP, the wrong mime type is probably given by 
> your web server. In this case, this is not OSX fault at all! It's your 
> web servers!

OK, much simpler exercise (OS X only):

Find an mp3 file on your hard drive.
Get info for that file.
Take note of:
  filename:
  type:
Rename that file, using finder
Get info for that file.
Take note of:
  filename:
  type:

I found the results to be very disturbing.  If you try it, I trust you will to.

If you renamed it .zip and double clicked, you'll see just how disturbing it 
can be.

> If you have an XHTML page with some inlined SVG, what MIME type is 
> that? XML (goes to my xml editor), XHTML (goes to my browser) or SVG 
> (goes to my vector graphics editor)?

Without much explanation i will claim that it's file type is xhtml.
Why?  Because it is xml and the root element is xhtml.  It would also
be correct to label it xml-- but that should only be done if you can't further
recognize it as an xhtml file.

It should not be recognized as an svg file, it is a compound file that embeds
an svg

> XML (goes to my xml editor), XHTML (goes to my browser) or SVG
> (goes to my vector graphics editor)?

WOW, talk about a mixture of concerns--
So what should be able to open it?

text editor, text viewer
xml editor, xml viewer
html editor, browser (html viewer)
svg editor, svg viewer

If you have this xpath enabled filesystem you're talking about,
then the finder should be able to open it too.

maybe some others.

Now what actually should open it when you double click on it--
or furthermore, how should that be decided?

Obviously the decision should belong to the user of the shell.  It may
be decided ahead of time and stored as some sort of preference.  
Where should the preference be kept?  As meta data of the file? or meta
data of the shell user?

> 
> MacOS got it right in separating type from name. POSIX got it dead 
Indeed OS9 had it right.  POSIX may have it wrong, but they do better than
file extentions.  The problem with explicit meta-data, including file 
extensions for that matter, is that it can lie-- and you get profound failure 
as the mp3 demonstration above shows.

> NOTE: even web servers that mount one2one the URL space to the FS space 
> share the exact same design mistakes. The Cocoon2 sitemap was 
> introduced exactly to solve those problems.
I agree with this.

> 
> The problem is much more complex than you outlined.
Of course it is.

Tim

Mime
View raw message