cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] Moving towards a new documentation system
Date Sun, 12 Oct 2003 16:21:31 GMT

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.


Mime
View raw message