Andreas Hartmann wrote:
> Hi Lenya devs,
>
> IMO it would be very convenient to agree on a uniform syntax for
> addressing documents. This could be used as a parameter for the
> doc-info module, for internal links, etc.
++votes**2
> The parameters which have to be contained are
>
> - publication ID
> - area
> - uuid
> - language
thinking out loud, correct me if i'm wrong.
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?
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?
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.
[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.
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.
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...
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.
(since most parts of this mail is only distantly related to andreas'
original inquiry, i suggest you consider replying directly to his mail
and only follow this thread if you want to comment specifically on my
ranting.)
jörn
--
"I don't need backups. I need restore!" - Trad.
--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: [EMAIL PROTECTED], Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
