Andreas Hartmann wrote:
Joern Nettingsmeier wrote:
Andreas Hartmann wrote:
Hi Joern,

thanks for your comprehensive comments!

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

+1 for all-in-one-box, but -1 for adding it to the per-{UUID+lang}
metadata. that's suboptimal from an index efficiency pov. the
publication should maintain a list of which UUIDs belong to it. this is
also easier to debug, since you can see everything at one glance.

Is this list really necessary? Maybe we can just assume that a publication
"contains" all documents which are referenced in its site structure.
According to your area interpretation, that would mean a global trash,
though. But with a lucene index for the publication-id meta data attribute,
searching the trash wouldn't be a big issue.

i don't like a global trash at all.

and i don't buy the "lucene index as a core mapping mechanism", until it has been demonstrated that
a) we have a watertight re-indexing trigger with no concurrency issues;
b) our indexing handles access control restrictions correctly in all cases, and does not leak protected information via the search results page.

moreover, the property "belonging to <pub>" is orthogonal to revisions,

Is it? Moving a document to a different publication would mean that the
next revision has a different "belongs to <pub>" value than the former one.

we should not bother about moving documents. if users want to do it, they can copy the content, paste it into some other pub and delete it in the old one. moving stuff around including history, revisions and metadata is a world of pain once you start thinking about access control, and frankly i think it's not worth it.

[terminology]

so let me propose the following:

<section status="draft" normative="yes">
the entirety of all data pertaining to what is traditionally called a
"web page" is called a *document* within lenya.

IMO that is a page, which is created by expanding a document.
Expanding means that all inclusions are resolved, e.g. the document might
be a list of <ci:include> statements, but the page shows a list of blog
messages.

yeah, obviously correct, solprovider mentioned the same. since it is just an example, let's get rid of it.

documents are uniquely identified by *UUIDs*, which may therefore be
called *document UUIDs* for extra clarity.

+1

documents contain one or more *translations*. "translation" here refers
to the actual content, and includes the "original language version",
being a general category.
each translation has *metadata* associated with it.

+1, whereas the document has meta data as well which apply to all
translations.

not yet iiuc. or does it? but i would welcome such a scheme.

lenya:// is one layer below this, it addresses repository nodes.

does that mean that it's obsolete now? or if not, what is it currently
used for?

It's used for addressing repository nodes. For instance, each document
has a repository node for the content and one for the meta data, and the
sitetree has a repository node for its XML, and so on. You shouldn't use
lenya:// in a pipeline, it is for internal use only.

C|N>K

ah. i see.

hear, ye users: you are using a cms named lenya. it implements a source factory with a protocol "lenya". it adresses repository nodes (as you may have readily inferred from the name), but you are not to use it, it's for internal use only. this is a most brilliant specimen of a naming (and namespace) fuck-up, and illustrates my point quite well :-D



--
"Open source takes the bullshit out of software."
        - Charles Ferguson on TechnologyReview.com

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

Reply via email to