cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <>
Subject Re: [RT] Moving towards a new documentation system
Date Sun, 12 Oct 2003 10:05:01 GMT
On 11.10.2003 17:19, Stefano Mazzocchi wrote:

>>>> ...How about naming files like
>>>>   3948494-some-descriptive-name-for-humans-here.xml
>>> It's like suggesting to have a BugID "39484-my-file-can't-be-found" 
>>> as the primary key of the bug table in mysql, just because people 
>>> might want to edit bugs by hand inside the database!!
>>> When you have bug emails, you get the bug ID which is unique and 
>>> semanticless....
>> You usually get the bug ID *and* the title, which lets you decide 
>> whether you're interested in it or not without having to look up the ID.
> yeah, but my point is that we should make it hard for people to edit 
> stuff in the repository directly. Accessing a WebDAV repository directly 
> should be considered a side access for administration purposes, not a 
> direct interface (unless there is a webdav-app in between, but that's 
> another story)
> just like you use the bugzilla frontend to edit the bugs, you don't do 
> it by hand by editing tables because you don't know how many things 
> could be triggered in the database by changing one table.
> a repository is just like a database: editing a database by direct SQL 
> injection is silly. Today it doesn't look silly because repositories are 
> *much* less functional than a database, but when you have a *serious* 
> repository (for example, one that can extract properties from an image 
> and provide an RDF representation for it), editing it *by hand* would be 
> silly.
> In this context, having a file with a numerical name, is just like 
> having a node in a JSR 170 repository with a unique UUID... which is the 
> basis for having the node linkable.
> but from a higher point of view, a LO is actually identified by a number 
> (or the timestamp of creation, anything unique and that can last 
> forever)... if you add a semantically meaningful name, this means that 
> you have to rely on that name to still be semantically meaningful in the 
> future... and different enough to allow to have thousands of documents 
> without incurring into name collisions.
> 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:

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 

It's similar for,1518,269451,00.html

 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.

is better in handling date information, but they don't provide 

I like much better the handling at

You get the date and what's the article about.

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.

What we need is the content of a page, not the date of its creation (but 
maybe this helps too, something like "latest update"). 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. 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 :-)

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, 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 You 
have to do exactly the same for the number URLs. So I think there is no 
problem with "everlasting semantically meaningful names".



View raw message