On Sunday, Oct 12, 2003, at 12:05 Europe/Rome, Joerg Heinicke wrote:
I think it's just easier to use a number.
I don't like the idea of having simply numbers in the URL. Let's have a look on the following URLs:
http://www.sueddeutsche.de/deutschland/artikel/420/19401/
Sueddeutsche online has an unique identifier (19401) in its URL that is simply counted up. Additionaly you have a classification (deutschland, artikel) and a number I don't know what for. But this additional stuff is useless (maybe it's useful for faster repository access). For a news page IMO it's important to have a date in the URL. They link to other articles without any date information. You have to click on them to know the date (or you can calculate them back from the ID), that's not good usability.
It's similar for
http://www.spiegel.de/sport/formel1/0,1518,269451,00.html
eheh, gotta love Vignette ;-) [part of those numbers identify the cluster machine! *that*'s hacky!]
From the URL you can not even guess from what date it is. But they provide at least the date information when linking to another article.
http://www.heise.de/newsticker/data/psz-11.10.03-002/
is better in handling date information, but they don't provide classification.
I like much better the handling at
http://www.xml.com/pub/a/2003/09/17/stax.html
You get the date and what's the article about.
but you are talking about news and articles, which are immutable things.
our learning objects are not immutable. for example, I could change their title as I go. Also, adding a date to a learning object is bad: should I change the date everytime I update it? if not, why would I care about the date it was first created?
Now we are no news page, so the above is maybe a bit to far from our needs, but it expresses my thoughts about a URL: It should give as much info as possible.
Believe me, I thought about this for years now. URI schemes vary depending on your needs.
Years ago, I though that URIs had to be semantic. I was wrong. I was mistaking URIs for URLs.
Moreover, semantic URLs tend to be more fragile because associated with the content they contain.
I have no problems for a URL such as the xml.com one. It's clean and persisting, but it can't be applied to the same things.
What we need is the content of a page, not the date of its creation (but maybe this helps too, something like "latest update").
latest update would continously change the URL.
The reason for the content in the URL is the fast access to a page (you already accessed some time ago) without navigating from start page.
You start to type in the URL bar and Mozilla completes it as far as possible. But if you only see numbers you don't know which one it was. (It's the same with the autocomplete function using tabulator on linux commandline.) It's especially the reaccess of a page which gets complicated by using numbers.
This is a very good point.
And if you have customized and learning trails you will possibly "never" find a way back to the page you want to access - similar to customized menus in Windows or MS Office, when you are searching for an entry which was there yesterday, but is no longer :-)
eheh :-)
The possible collision of names should be handled by the repository.
Remain the "everlasting semantically meaningful names". Of course the URL should match the content. But if the content changes, so that it no longer matches, what's the sense of having still this page? Even if you use IDs and change the content later, the user linked from outside to this page gets other content than he wants to have. So there must be available an "outdating mechanism". Let's say there is a page http://cocoon.apache.org/documentation/tutorial/xmlforms.html, which is linked often from outside, because it was the one and only form handling in Cocoon. Now in Cocoon 2.2 or 3.0 XML Forms are removed completely, but we don't want to give the user a simple 404 page. We have to point out that he can "use Woody or Cocoon forms which is by far better than XML Forms" with a link to the correct page http://cocoon.apache.org/documentation/tutorial/cocoonforms.html. You have to do exactly the same for the number URLs. So I think there is no problem with "everlasting semantically meaningful names".
you have a point there, that's for sure.
I'll think about this some more.... do you have any suggestion?
-- Stefano.
