cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] Moving towards a new documentation system (was: [RT] Updating the website)
Date Sat, 11 Oct 2003 13:33:20 GMT

On Saturday, Oct 11, 2003, at 14:58 Europe/Rome, Bertrand Delacretaz 

> Le Samedi, 11 oct 2003, à 14:11 Europe/Zurich, Stefano Mazzocchi a 
> écrit :
>> ...I think the documents should have a *numerical* identifier that 
>> equates them with a URI.
> I like the "unique ID" idea, OTOH not having descriptive names makes 
> it hard for people to locate the appropriate file to edit in a 
> directory, decode CVS change messages, etc.
> 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. if the bug changes course over time (might even change 
title in the more advanced tracking tools!), the "issue" is the same 
and can change without breaking because the contract is nameless.

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.

> Where what follows the first dash is ignored by the publishing system 
> (which will need to check the uniqueness of IDs then)?

Messy. what would something like this behave?


>> ..where "LO" stands for "learning object".
> hehe ;-)
>>> ...-create a very simple publishing system for now (Forrest 
>>> probably?), until the new docs system moves forward
>> a first step could be the introduction of files that contain 
>> navigation structure. They could also be xslt processed to generate 
>> .htdocs file for mod_rewrite instructions so that we don't expose 
>> those URI directly but we wrap them with nicer-looking addresses.
>> [it's the static equivalent of a lookup]...
> Sounds good.

or we might use site:-based address translation capabilities of 
forrest. even if I'm not exactly sure on how this works (haven't look 
at forrest in a long time).

>>> P.S. We need to find a name for this new doc management system - I'm 
>>> low on ideas noew but maybe CDMS? Cocoon Documentation Management 
>>> System?
>> -1 for acronyms.
> Actually I don't like them either ;-)
> But we need to name this thing at some point.


I had two names "Hyperbook" and "Papyrus", but both are probably 
infringing some trademark. I'll try to come up with something that is 
"print" or "publishing" or "learning" related.... if you have a 
suggestion, it's a good time to speak up.

NOTE: this is *NOT* something that will replace either forrest or 
lenya. In fact, the idea of this system is to show off *all* the 
cocoon-related technologies we have in one big showcase for our own 
use. So, both forrest and lenya should be happy to participate into 
this because it might give them even more exposure and ideas for new 
features or simply more itches to scratch that would revamp the various 


View raw message