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
Date Sat, 11 Oct 2003 15:38:53 GMT

On Saturday, Oct 11, 2003, at 16:54 Europe/Rome, Nicola Ken Barozzi 

> Bertrand Delacretaz wrote:
> ...
>>> ...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.
> Look at Forrest, we have been having super-easy revision for a while 
> now.
> howto-multi.xml
> revision-howto-multi-2003-09-14.xml
> revision-howto-multi-2003-09-15.xml
> Here is how it shows:
> So you always get the latest version and can also see the revisions.

cool. it would be piece of cake to have different *views* of the 
learning object's revisions so that forrest can rely on something like 
the above.

>> 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 
>> "communicable".
> I really think that using ids /instead/ of filenames is not a good 
> idea.
> URIs are about where to find a certain information, not necessarily 
> with a specific date version.

No, URI are identifiers, URL are locators. A URI *can* be used as a 
URL, but the results is unknown and has to be decided case by case (as 
for namespaces, for example).

A learning object (think of it as the abstraction of what a page is) is 
a container of information and needs to be identified uniquely, 
allowing the content to evolve without require a change in 

Versioning is an orthogonal identification axis and can be composed to 
provide a bi-dimensional identifier so

identifies to the learning object 3984, but doesn't specify with 

specifies LO #3984 with revision 343. Note how if the URI is used as a 
locator, the resulting LO is immutable.

don't look at the syntax of the IDs, an alternative syntax could well be

and the meaning is exactly the same.

The behavior of using the URI as a locator is dynamic. For example, at 
one point in time


might locate the same learning object, because revision "394" is the 
last one.

How this maps to the file system is completely irrelevant because the 
repository represents a virtual one.

> That's why the Forrest revisions have a defined date (or number) in 
> the name, so that that stays the same.

see above, same thing, just must abstract, totally decoupled from the 
actually implementation of the storage.

> What I would propose, and that I would like to implement, is an 
> indexing system that scans all source files and associates a number 
> with that file.

that's the job that our repository would do for us transparently.

> This means that a file can have a barcode attached to it, and if we 
> keep a repository of site barcodes, we can have a fully resolvable 
> barcoded page.

welcome to the world of content repositories ;-)

> Then, when pages are added or changed, the system would index the 
> files again, and add other new pages with incremented numbers.

JSR 170 will allow us to do this and *much* more.

> Note that there is another trick in this: if I also index site.xml, I 
> can get to know the *history* of the site: ids, and can automatically 
> do redirects.
> For example, I start with this site.xml.
>  <site label="My Site">
>    <mynicepage label="Nico Page" url="nicepage.html"/>
>  </site>
> I can refer to that in my docs as:
>   <link href="site:mynicepage">
> (note that site nodes can be hierarchical)
> Then one day I change the node to be:
>  <site label="My Site">
>    <mynicepage label="Nico Page" url="newnicepage.html"/>
>  </site>
> The system would understand that the node leads to another page, and 
> would generate redirects from the previous link to the new one.
> Of course, we can do this *if* we don't create different pages at the 
> same old locations, unless we generate URIs following site.xml instead 
> of the file structure (I do not reccomend ATM).

hmmm, I have to think more about this...


View raw message