xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: How to use XML to link to XML when the XML becomes HTML?
Date Mon, 03 Apr 2000 11:52:16 GMT
Dan Morrison wrote:
> 
> 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?)

You're looking from the wrong side of the telescope :)

 <img src="/logo"/>

and if you want to filter out images, you tell the spider not to do it.
Taking JPG and leaving GIFs, it's like saying "keep the ones with 24bit
colors and remove the ones with 8bit colors"... so how do you make that
more efficient? logo.8bit.gif so that your spider is happier?

I hope you understand this is a dangerous patch to follow. Like every
hack, this works if the complexity is kept to a minimum.... but it
normally shows problems when you start doing nasty tricks with it.
 
> > > 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?

you're totally right. See how deep those anti-patterns go?
 
> > 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

No, I'm serious, ext3 _SHOULD_ have MIME-type information for the inode
stored... (not the entire string... a code that maps to an extensible
list of MIME types) this would be an incredible feature for the linux
operating system that would kick asses in the future when more and more
people will understand the need for a better URI mapping abstraction,
but don't want to loose performance.
 
> > 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? 

MacOS is the only one I know.

> All my graphical Linux interfaces are
> behaving just like Windows - showing me icons chosen by suffix,
> associating viewers with them automatically the same way. 

Yep... this is because both FAT, ext2, NTFS don't store file-type
information in other places but encoded in the file name. Looking from
this angle, doesn't it sound bad?

> 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...

probably so... anyone?
 
> .
> .
> As you say, just because it's everywhere doesn't make it good.

Yep. The hard part is not technical... is to change people perception
there is no alternative.

> .
> .
> 
> > 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?

it depends: if mapping inside Apache is done right, probably not or
something that barely impact your system.
 
> > > 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!

Answer my question: why in the world you access a URI? to get
information about something.

You expect to have _lots_ of reasoning being put on the other side of
the fence about _what_ is the best option for you, depending on your
client capabilities (are you browsing from your car? from your desktop),
client rendering capacity (do you have the xxx plugin installed? able to
listen to MP3?), or your user preferences (your cookie tells the site
you love fancy art even if slower, but you hate flash crap)...

Can you possibly encode all that in a single file extention? and even if
you did, what would you gain?

http://xml.apache.org/cocoon/dist/

is the place were Cocoon is distributed. How do you know what is on the
other side? an HTML page, a WML page, a directory listing, a java applet
with super-crypto capabilities?

But the anserw is: I don't care, as long as you give me what I was
looking for.

Sure, then you can complain that your super-crypto applet is slow as
hell and you don't care about such security... but this is like
complaining for a site that has weird colors... nothing to do with the
technical details involved...it's another layer.

> It does bring to light the whole conceptual difference between a
> Resource and an accessible File.

I'm really glad it did.

> I'm sure you've preached this before, but it can be a bit of
> double-think to us less-enlightened ones.

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

Take a look at the Cocoon2 white paper.. you might find good ideas for
you there.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------



Mime
View raw message