On Saturday, Oct 11, 2003, at 14:58 Europe/Rome, Bertrand Delacretaz wrote:
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.
http://cocoon.apache.org/cocoon/LO/3948494
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?
22003-this-is-first-doc.xml 22003-this-is-second-doc.xml
..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.
True.
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 communities.
-- Stefano.
