Mailing-List: contact general-help@xml.apache.org; run by ezmlm
Message-ID: <38E7D173.35BB@es.co.nz>
Date: Mon, 03 Apr 2000 11:02:12 +1200
From: Dan Morrison <dman@es.co.nz>
Organization: Disorganised
MIME-Version: 1.0
To: general@xml.apache.org
Subject: Re: How to use XML to link to XML when the XML becomes HTML?
References: <3.0.32.20000330074658.01a933a0@pop.intergate.ca>
 <38E36AF2.1789@es.co.nz> <38E482A0.FDCDBD2F@apache.org>
 <38E4A9A3.1F55@es.co.nz> <38E4CFEA.F410B195@apache.org>
 <38E5ABDA.3866@es.co.nz> <38E5D565.F98CAA79@apache.org>
 <38E6CCB4.5E12@es.co.nz> <38E7D960.A7E483A6@apache.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stefano Mazzocchi wrote:
> 
> ???, I think I lost you here.

OK, I'm gonna retreat here. Most of this thread just started off with me
trying to find a way around renaming doc.xml to doc.html without using
substrings. I'm now out of my depth with deep anti-patterns :-\


> So you agree with IE that first looks for suffixes and if not found
> looks for MIME-types? You can' t be serious on that.

Not in as many words, no. At least MIME should take priority once it's
known. But there IS information there. Write a spider and you don't want
to grab every jpeg, so you filter the suffix etc... (cmon, header
requests for every gif?)

> > A common example - a default directory listing in Apache :-)
> mod_magic does this using magic key introspection, not suffix.

Um, I realize you're way the expert here, but don't the lines
-- AddIcon /icons/layout.gif .html .shtml .htm .pdf
-- AddIcon /icons/text.gif .txt
do just this? In one scenario at least?


> I'm sure MacOS people don't agree with you :) 

Ooooh yeah, lets store meta information about the file type in a hidden
file somewhere nearby. Great. ;-p


> The whole problem is _NOT_
> with URIs but with file systems that do not include the MIME types of
> their hosted files, but use an encoded suffix to the file which can be
> modified by simply renaming the file.
> ....
> If you think about it, the whole "file.ext" things is a hack that we
> drag up-hill since IT ages. So much that the same exact problem went
> reflected into URI spaces.
> 

I 100% agree. :-) 
I did note this historical hack bit earlier.

> This doesn't mean there are not better approaches.

So ARE there any such systems? All my graphical Linux interfaces are
behaving just like Windows - showing me icons chosen by suffix,
associating viewers with them automatically the same way. This is why I
compared the existing methods to Apache dir listings & graphical ftp.
It's everywhere. If there was a better way (I agree there should be) I
haven't seen it. 
I guess it must be out there on some obscure *nix system...

.
.
As you say, just because it's everywhere doesn't make it good.
.
.

> this is exactly the point: the user is accessing a resource, not a
> file on your disk.

OK, I see where you're coming from.

> It's more secure if he doesn't know _anything_ about
> that on your system.

Somewhat less efficient? 

> > Currently, you look at an URL with no suffix, and you guess that it's a
> > link to a section of a site
....
> Hmmmm, what about having an XML database that contains all the
> information about Dante Alighieri in a file, then performing an XQL
> query on that file based on that URI, then apply an XSLT transformation
> sheet and present it to you?
...
> Could you tell from the URI?

Quite right. That is a fantastic application. One I would not have
assumed from the URL, but of course is common enough. (Sorry Cocoon was
not upmost in my mind) It is however opaque. 
You argue that this is better. ... um OK it is :-) Sorry. ... 
I STILL don't know If I'll find HTML or Real Audio at the end of that
link!

It does bring to light the whole conceptual difference between a
Resource and an accessible File. 
I'm sure you've preached this before, but it can be a bit of
double-think to us less-enlightened ones. 

Thanks for your illumination. I'll go back to my XSL substrings now :-{

Cheers, 

.dan.