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.
