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 Sun, 02 Apr 2000 23:36:00 GMT
Dan Morrison wrote:

> > Maybe for HTML pages it's not obvious but if you do
> >
> >  <img src="/images/logos/main">
> >
> > then you are able to reuse that URL for "all" instances and all your
> > user devices. Think about WAP phones, low graphic users, SVG capable
> > clients, TV-sets, etc...
> This is indeed the functionality I want! And this is why I would like to
> split the suffix off from the filename. But doing so would promote the
> suffix to being an individual fragment of a URI breakdown.

???, I think I lost you here.
> > > Mime-headers & stuff only happen post request.
> >
> > Yes, that's the beauty of it.
> OK, You've lost me there. 

Sounds like our comm-link is not that reliable :)

> Mime negotiation is more robust at runtime,
> but if the suffix was reliable as a content indicator, things are much
> more efficient.

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.

> A common example - a default directory listing in Apache :-)
> I get presented with a bunch of icons that the server has chosen to map
> to mime-types which are in turn mapped to suffix.

mod_magic does this using magic key introspection, not suffix.

> Without that short-cut, would it be appropriate for MY browser to
> request the type of each resource  and then choose an appropriate icon?

the icon is passed to you by the server, your browser simply displays
what's sent.
> I realize I'm clouding the issue with client tasks vs server tasks, but
> the logic holds. I run a graphical FTP program, it displays remote files
> with icons chosen from file suffix, and chooses binary/ascii mode based
> on those decisions.
> Thanks to the existance of the suffix, I have a better idea about the
> content of the file I'm getting. This is why I say the suffix is as
> important as any other part of a URI.

I'm sure MacOS people don't agree with you :) 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.

Tell me, if I rename "hello.xml" into "hello.jpg", does this make the
file an image?

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.

This doesn't mean there are not better approaches.
> > > > If you type
> > > >  http://www.apache.org/index.html
> > > > you do two mistakes, even if the outcome is the same:
> > >
> > > Yet another reason for me to detest FrontPage [Spawn of the Devil TM]
> >
> > No, it's a reason to detest closemindness.
> Um? I dunno about everyone else, (I can guess) but looking at my
> bookmark list I find that over 80% of my links are in just such a
> 'closeminded' format. That is, I have linked to a page blah.html. Most
> link pages in existance are similar. If this approach is so evil... why
> are things that way?

Like I said: people are so used to this, they don't even think about
better ways of doing it.
> However, I am personally advocating being able to refer to documents
> sans suffix, So I'll get on that particular bandwagon if neccessary.

It's not necessary... after reading papers about this, I find file
extentions an anti-pattern and they should be avoided whenever possible!

> > > All of which makes creating a directory for each file and linking to the
> > > directory seem more inviting.
> >
> > You think? Ok, do it for a site with two hundred million accessible URIs
> > and come back to me.
> I am NOT serious (I was referring to an earlier speculative posting).

Oh, sorry then.
> It's just that the most straightforward way (I can see) under current
> technology to make your way of linking to
> > > http://www.amazon.com/books/it/Dante_Alighieri/La_Divina_Commedia/paperback/comments
> actually _work_ is to have a file called index.html iside your directory
> called ../comments/
> OK, you can pull some tricks with URL rewriting, but that makes it
> opaque to the client, and prevents the user from knowing what it's truly
> accessing.

what? this is exactly the point: the user is accessing a resource, not a
file on your disk. It's more secure if he doesn't know _anything_ about
that on your system. Also, it's more portable for you in the future
since you can map that resource to a database-driven generator, an XML
publishing system, a legacy connection, and whatever comes next.

To me, it appears that one/one URI -> file linking is closing people's
mind on the server side... and it's not about mod_rewrite and hacks like
them. It's about resource mapping, which is mostly unrecognized as an
engineering practice at this point...

.. thing that creates the broken-link plague.
> Currently, you look at an URL with no suffix, and you guess that it's a
> link to a section of a site. That is, a directory. Which will in turn
> serve it's index page or whatever...
> I look at your ../comments example, and that's what I assume.

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?

All the "http://www.amazon.com/books/it/Dante_Alighieri/*" URIs are
driven by the same XML file, just using different queries based on the
full URI and different stylesheets based on the requesting client.

Could you tell from the URI?

> In a better world (where linking actually is clever enough to do what I
> originally posted this thread about) Your example WILL indeed be mapped
> to  ../comments.*** where *** is your medium of choice. Current clients
> do not do this however.

This is _NOT_ something that is client-side related. 
> I thought this was a possible application of Xlink. Seems not.

You're right. This is never a client side feature.
> I think (and it appears you do to) that this is a fine direction to be
> moving in.
> Sorry you disagree that separating the suffix from the filemane is
> significant, but glad you think that the filename should be able to
> stand on its own. Maybe we're halfway here.

I wrote Cocoon to cover that other half :) and I must say that thanks to
a wonderful set of other guys Cocoon2 will reach the point where
everything I said above is in your reach with the browser that you have

Like I said, the real XML battle is on the server side :)

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

View raw message