cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bertrand Delacretaz <>
Subject Re: [RT] Moving towards a new documentation system
Date Sat, 11 Oct 2003 14:20:37 GMT
Le Samedi, 11 oct 2003, à 15:33 Europe/Zurich, Stefano Mazzocchi a 
écrit :

> On Saturday, Oct 11, 2003, at 14:58 Europe/Rome, Bertrand Delacretaz 
> 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.

> ...Think about TCP/IP: instead of placing a human identifier at the IP 
> level, they used a lookup mechanism. This is exactly the paradigm that 
> we should follow, IMO.

Agreed, provided the usability of this lookup is good enough to:
-Easily find out what learning object a CVS (or other "change event") 
message is about
-Easily select a learning object for editing, review, etc, without 
needing complex tools

Also, the comparison with TCP/IP brings another idea, instead of using 
big numbers for IDs they could be split like IP addresses to make them 
more readable.

Some people have a hard time reading long chains of numbers, I am one 
of these and for me


is much more easier to read (and to spell out) than


Where I have a hard time figuring out the number of 3's and 2's (you'll 
see when you are my age ;-)

I'm using 2003 in front as starting with the year in which the ID was 
assigned gives some useful context. Mixing concerns, I know, but also 
makes for an easy way of splitting LOs in subdirectories for storage, 
to avoid having millions of files in a single directory.

> ...Messy. what would something like this behave?
>  22003-this-is-first-doc.xml
>  22003-this-is-second-doc.xml
> ...

that's what I meant by the system having to ensure the uniqueness of 
IDs. It is certainly problematic.

I agree that a pure ID for naming pieces  of content might be better, 
provided lookup is super-easy and doesn't get in the way of editing, 
keeping track of changes etc., and the ID's stay readable and 


View raw message