You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@xml.apache.org by Dan Morrison <dm...@es.co.nz> on 2000/04/01 09:57:14 UTC
Re: How to use XML to link to XML when the XML becomes HTML?
Stefano Mazzocchi wrote:
> > IMO, the suffix of a file in a URI is a first-class citizen, deserving
> > attention equal to the protocol.
>
> Why?
Granted that suffix-mime mapping has some things against it, it is one
way of telling the type of the resource being linked to. This allows the
client to know what it is that it's requesting - surely thats important?
I see .../contents.gif, .../contents.html, .../contents.xml,
.../contents.php at there is information that is very imformative to me.
Mime-headers & stuff only happen post request.
> In the awesome article "good URIs don't change" by web creator and W3C
> director Tim Berners Lee, it is clearly shown why URI represent "uniform
> resource identifiers"... this means:
>
> uniform: they should identify _any_ available network resource
> resource: something that you are able to access from your network
> identifier: a unique address for that resource
OK, but we've seen information get a little more abstract & relative
than that model, which is I guess where Xpointer comes in. Doesn't
quite meet my current needs.
> 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]
... Now, what happens if you change technology and
> go to, say,
>
> http://www.apache.org/index.xml
>
> all of the sudden, all the links are broken.
All of which makes creating a directory for each file and linking to the
directory seem more inviting.
....
> This is a simple and stupid example, but think about URIs like these
>
> http://www.amazon.com/books/489347898387794?a=4898&b=4880
>
> compared to
>
> http://www.amazon.com/books/it/Dante_Alighieri/La_Divina_Commedia/paperback/comments
>
> which one is better?
>
> Tell me, which one is more likely to remain the same after a hundred
> years?
I notice that 'comments' at the end of the path doesn't have any suffix.
I want (will I think I do) those files listed earlier to be .../contents
and my parser will request centents.xml or content.html as appropriate
in context.
Sound ridiculous?
Re: How to use XML to link to XML when the XML becomes HTML?
Posted by Stefano Mazzocchi <st...@apache.org>.
"Max R. Andersen" wrote:
>
> >>>>> "Stefano" == Stefano Mazzocchi <st...@apache.org> writes:
> >> > 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?
>
> Stefano> MacOS is the only one I know.
>
> Just to inform you'all :)
>
> BeOS also store the MIME type on its filesystem(BFS)
Uh, didn't know that. Thanks for the info.
> --
> Max R. Andersen (max@cs.auc.dk)
>
> ps. BeOS 5.0 just got released for FREE - try it, you will not regret
> it - this OS is way to cool! With emphasis on cool!
I will!
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: How to use XML to link to XML when the XML becomes HTML?
Posted by "Max R. Andersen" <ma...@cs.auc.dk>.
>>>>> "Stefano" == Stefano Mazzocchi <st...@apache.org> writes:
>> > 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?
Stefano> MacOS is the only one I know.
Just to inform you'all :)
BeOS also store the MIME type on its filesystem(BFS)
--
Max R. Andersen (max@cs.auc.dk)
ps. BeOS 5.0 just got released for FREE - try it, you will not regret
it - this OS is way to cool! With emphasis on cool!
Re: How to use XML to link to XML when the XML becomes HTML?
Posted by Stefano Mazzocchi <st...@apache.org>.
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.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: How to use XML to link to XML when the XML becomes HTML?
Posted by Dan Morrison <dm...@es.co.nz>.
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.
Re: How to use XML to link to XML when the XML becomes HTML?
Posted by Stefano Mazzocchi <st...@apache.org>.
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
_today_.
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.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: How to use XML to link to XML when the XML becomes HTML?
Posted by Dan Morrison <dm...@es.co.nz>.
Stefano Mazzocchi wrote:
>
> > This allows the
> > client to know what it is that it's requesting - surely thats important?
>
> ??? why?
For EXACTLY the same reason you might like to know what the mime-type
is. So you know how to display the thing. And the added value is you
know beforehand whether the browser can handle the content and whether
to present it as an option.
> > I see .../contents.gif, .../contents.html, .../contents.xml,
> > .../contents.php at there is information that is very imformative to me.
>
> To you "site creator" or to you "site user".
Mainly as a user. _I_ know that a php is likely to be dynamic, that
might affect the way I treat that link. I know that if I follow a link
to a contents.wav file I'm unlikely to be presented with an image.
> 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.
> > Mime-headers & stuff only happen post request.
>
> Yes, that's the beauty of it.
OK, You've lost me there. Mime negotiation is more robust at runtime,
but if the suffix was reliable as a content indicator, things are much
more efficient.
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.
Without that short-cut, would it be appropriate for MY browser to
request the type of each resource and then choose an appropriate icon?
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.
> > > 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?
However, I am personally advocating being able to refer to documents
sans suffix, So I'll get on that particular bandwagon if neccessary.
> > 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).
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.
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.
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.
I thought this was a possible application of Xlink. Seems not.
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.
cheers,
.dan.
:=====================:====================:
: Dan Morrison : The Web Limited :
: http://here.is/dan : http://web.co.nz :
: dman@es.co.nz : danm@web.co.nz :
: 04 384 1472 : 04 495 8250 :
: 021 115 7339 : :
:.....................:....................:
: If ignorance is bliss, why aren't more people happy?
:.........................................:
Re: How to use XML to link to XML when the XML becomes HTML?
Posted by Stefano Mazzocchi <st...@apache.org>.
Dan Morrison wrote:
>
> Stefano Mazzocchi wrote:
> > > IMO, the suffix of a file in a URI is a first-class citizen, deserving
> > > attention equal to the protocol.
> >
> > Why?
>
> Granted that suffix-mime mapping has some things against it, it is one
> way of telling the type of the resource being linked to. This allows the
> client to know what it is that it's requesting - surely thats important?
??? why?
> I see .../contents.gif, .../contents.html, .../contents.xml,
> .../contents.php at there is information that is very imformative to me.
To you "site creator" or to you "site user".
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...
If you say
<img src="/images/logos/main.jpg">
the whole points is gone... and if you do content-negotiation on top of
-that- URI (which you perfectly could), it's getting even more confusing
since you are requesting a JPG image and the server returns an SVG image
depending on your browser capabilities.
> Mime-headers & stuff only happen post request.
Yes, that's the beauty of it.
> > In the awesome article "good URIs don't change" by web creator and W3C
> > director Tim Berners Lee, it is clearly shown why URI represent "uniform
> > resource identifiers"... this means:
> >
> > uniform: they should identify _any_ available network resource
> > resource: something that you are able to access from your network
> > identifier: a unique address for that resource
>
> OK, but we've seen information get a little more abstract & relative
> than that model, which is I guess where Xpointer comes in. Doesn't
> quite meet my current needs.
I don't like XPointer and I think we don't need it.
> > 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.
> ... Now, what happens if you change technology and
> > go to, say,
> >
> > http://www.apache.org/index.xml
> >
> > all of the sudden, all the links are broken.
>
> 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.
> ....
> > This is a simple and stupid example, but think about URIs like these
> >
> > http://www.amazon.com/books/489347898387794?a=4898&b=4880
> >
> > compared to
> >
> > http://www.amazon.com/books/it/Dante_Alighieri/La_Divina_Commedia/paperback/comments
> >
> > which one is better?
> >
> > Tell me, which one is more likely to remain the same after a hundred
> > years?
>
> I notice that 'comments' at the end of the path doesn't have any suffix.
Yes, that's the point.
> I want (will I think I do) those files listed earlier to be .../contents
> and my parser will request centents.xml or content.html as appropriate
> in context.
>
> Sound ridiculous?
No, this is what I'm saying all along :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------