This page is meant to give you an overview of key concepts concerning the structure of Lenya publications. It is a companion document for the Glossary.

The terms presented here are currently debated. This page does not reflect or imply consensus. Think of it as a placeholder.

AndreasHartmann has posted an updated class diagram with his view of the current discussion: 14-repository-api.pdf (14-repository-api.graffle)


- Publication
- - Content
- - - Document (has Type, DocumentUNID, DocumentID properties)
- - - - Translation (has Language and LiveRevision properties)
- - - - - Revision (has CreationDate and Editor properties)
- - - Asset (has Type, UNID, ID properties)
[- - - - Translation (has Language and LiveRevision properties)]
- - - - - Revision (has CreationDate and Editor properties)

[pasted here by JörnNettingsmeier, errors are mine.]

JörnNettingsmeier, with ideas from BobHarner

- Publication
- - Site tree (one canonical, optionally others)
    contains (as nodes):
- - - Document (an abstract container for all assets)
- - - - Assets (text assets (in several language), images, media files, pdfs, etc)

Assets have revision control information.

Documents have a revision control information summary (the collection of all current revisions of their assets). Whenever one asset changes, the Document revision number is bumped.

This leaves the ugly "content item" out. It can be used internally to name abstract objects if needed.

I suggest to avoid the word "version" with any fixed connotations. For the "versions" of a document or asset as it changes over time, let's stick to "revision".

Currently, there is the term "resource type" for xhtml, links, opendocument etc. I suggest to change the name to "document type", analog to "DTD". "resource type" includes not only the schema definition but also the code needed to handle it. For that, how about "document type handler"?

Your 0.02 $CURRENCY here

  • No labels