Hi Joern,
thanks for your comprehensive comments!
[...]
iiuc, the only change to the old document-id semantics is that UUIDs are
sitetree-agnostic, i.e. IDs remain constant when documents are moved
around. correct?
Yes, exactly.
hence,
* UUIDs contain different translations
-> we need UUID+{language}
* UUIDs are shared among areas and revisions, i.e. the same UUID refers
to a number of physical storage directories.
-> we need UUID+{language}+{area} and assume current revision
* are UUIDs unique across publications?
-> if yes, {pubId} is redundant. do we want to drag it along?
It would be great if we could omit it, but this would require a
performant lookup mechanism. Or we just put all content in a
single box, and add the publication ID to the meta data. This
sounds quite appealing to me.
do we have to rethink the design to restore orthogonality?
-> if no, what's "unique" about them?
* UUIDs are definitely orthogonal to revisions. we do not need to access
revisions other than "current" most of the time, but we should make it
possible now in order to avoid having to tack on another mechanism for
situations where revisions are involved.
+1, this sounds useful.
[terminology]
are we realling "addressing documents"?
currently, i find in the sitemaps the term "document-uuid".
that implies we use the term "document" to mean "the set of all stored
data snippets (including meta) that corresponds to a particular UUID".
so we are not addressing documents. we are addressing particular
instances of a document in a certain publication, area and language.
At the moment, a document is a particular translation in a particular
area in a particular publication (we didn't yet change the terminology,
at least as far as the class names are concerned).
IIRC we agreed upon the term "translation" for this.
We don't have a class for "the object that contains all translations
for a UUID in a certain area" yet. That would be a document/resource/asset
(IIRC "document" was the preferred term).
this needs a new word that we must all instantly begin to use, and after
a grace period of 10 days, anyone caught confusing terminology should be
shot.
[areas]
thinking about andreas' suggestion, it becomes ever more evident to me
that the area concept is flawed. areas should be done in altogether in
the not too far future.
I agree that it has to be reconsidered, but should we address in 1.4?
here's why:
* areas currently imply multiple storage units with the same UUID. not nice.
* admin, trash and site areas are second-class citizens and are not
conceptually similar enough to warrant being called "areas".
* trash can go, since any UUID not currently referenced from the site
tree would be "in trash". that implies not throwing an exception
like we do now. trash would become a usecase that allows for
comfortable browsing of such "orphaned" UUID entities.
* most importantly, areas are *not orthogonal* to revisions. "live" can
become just another site-tree. this time pointing not just to UUIDs, but
to UUID+revision. authoring otoh implies "HEAD" revision on all UUIDs.
An internal link URL might look like this:
document://{pubId}:{area}:{uuid}:{language}
what about lenya: and lenyadoc:? i must confess i have never quite
grasped the concept...
lenya:// is one layer below this, it addresses repository nodes.
lenyadoc:// is probably fine for links. Maybe we should just use that one.
in any case, the protocol should definitely begin with "lenya...", so
that it's immediately obvious what's going on in the sitemap.
i would even go as far as suggesting that all our input modules and
pseudo-protocols that are not suited for upstream cocoon be re-named
lenya-fallback, {lenya-docinfo:...} etc.
this would greatly reduce the learning curve for our users, and make
life easier for casual committers from other apache projects, since it's
obvious if custom magic is at work, as opposed to core cocoon functionality.
-0.5, I'd prefer to keep them short, but it's OK with me to change it.
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
[EMAIL PROTECTED] [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
