cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
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 
wrote:

> 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:
> http://xml.apache.org/forrest/community/howto/multi/howto-multi.html
>
> 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 
identification.

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

  http://cocoon.apache.org/LO/3984

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

  http://cocoon.apache.org/LO/3948/343

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

  http://cocoon.apache.org/LO/003.048/3.43

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

  http://cocoon.apache.org/LO/3948

and

  http://cocoon.apache.org/LO/3948/394

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...

--
Stefano.


Mime
View raw message