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, 19 Oct 2003 19:07:18 GMT

On Sunday, Oct 19, 2003, at 19:54 Europe/Rome, Joerg Heinicke wrote:

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

hmmm, well, it depends.

The URI (we are talking about URIs here, not URLs, careful) of a LO 
will need an ID that identifies the object, then might (optionally) 
have another ID that identifies the version.

So, I would do

  http://host/path/ID

to identify the object in general and

  http://host/path/ID/version

to indicate the object version

> The IDs would allow to change the content without a latter mismatch 
> between URI and content.

Exactly.

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

This is a little bit more tricky. If you choose to use a timestamp for 
the version ID, then you have to make sure that you have enough 
granularity to take into account the minimum potential time in between 
two different changes might happen, or, again, you get a collision.

This is why I generally dislike the use of dates in URIs, version 
numbers are *abstract*, so

http://cocoon.apache.org/lo/39484/342

indicate revisions 342 of learning object 39484 and this does not 
change over time.

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

That means that you get a collision if you have more than one version 
of the documents per a given date, and this is very likely to happen.

> We only need a repository handling this. With plain html lying around 
> in a directory it's not doable I guess.

It could be virtualized (linotype already does versioning as mentioned 
above, it's just turned off by default as it wasn't stable and I didn't 
have time to clean it), but yes, a repository would be a much better 
choice.

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

Good point (didn't think of this, actually)

> One point is not handled: the autocompletion functionality of the 
> browsers.

Yep.

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

Well, Mozilla does the right thing and I think IE will follow. I 
wouldn't want to make a compromise because of weak browser 
implementations.

But also note that we are still talking about URIs not URLs. Using the 
LO URI as a URL might not be the only way to access the object.

> I don't have a solution for it, maybe it's not that important or at 
> least one compromise must be done.

I agree.

--
Stefano.


Mime
View raw message