Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <3F92CFDF.3090801@virbus.de>
Date: Sun, 19 Oct 2003 19:54:39 +0200
From: Joerg Heinicke <jheinicke@virbus.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.5) Gecko/20031007
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [RT] Moving towards a new documentation system
References: <23C3CAA8-FCD0-11D7-B7DA-000393D2CB02@apache.org>
In-Reply-To: <23C3CAA8-FCD0-11D7-B7DA-000393D2CB02@apache.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Late, but ...

On 12.10.2003 18:21, Stefano Mazzocchi wrote:

...

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

Maybe the title, but not the content in general/completely - as you
already agreed below.

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

Read on below.

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

...

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

I read today "Cool URIs don't change" [1] for preparing the answering of 
your mail. And there are not many options left after reading it: The 
URLs of a learning object need an ID and a modification date, not more, 
not less. The IDs would allow to change the content without a latter 
mismatch between URI and content. The date assures that a later access 
to a linked page has the content it should have, it can not have been 
changed in the meantime. The user would always access a page where the 
content is appropriate to a certain date, similar to "cvs co -r 20030303 
lo/1234567890.xml". We only need a repository handling this. With plain 
html lying around in a directory it's not doable I guess.

[2] also stands on 78 character URLs for avoiding breaks in mails. The 
above should be perfect for it, while at the moment our URLs are often 
longer than 78 characters.

One point is not handled: the autocompletion functionality of the 
browsers. Mozilla mentioned above was not the best example, because it 
provides additionally at least the title in the URL bar when using 
autocompletion, but IE does not. I don't have a solution for it, maybe 
it's not that important or at least one compromise must be done.

Joerg


[1] http://www.w3.org/Provider/Style/URI.html
[2] http://www.useit.com/alertbox/990321.html