On Saturday, Oct 11, 2003, at 16:54 Europe/Rome, Nicola Ken Barozzi wrote:
Bertrand Delacretaz wrote:
......Messy. what would something like this behave?that's what I meant by the system having to ensure the uniqueness of IDs. It is certainly problematic.
22003-this-is-first-doc.xml 22003-this-is-second-doc.xml ...
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.
