[EMAIL PROTECTED] wrote:
[...]
I mostly agree to that, but IMO changing an existing definition
is OK if it helps conforming to points 0 and 1. As I understand it,
the term "asset" is commonly used by other CMS (please correct me
if I'm wrong).
5. Lenya 1.2 defined "Usecase" as "special process separate from the
primary process". General Usage defines "Usecase" as "Real world
actions required to complete a task". There was a major discrepancy.
Lenya 1.4 changed the term to "Module".
That's not quite correct, usecases and modules are not the same.
A usecase is an action controlled by parameters, it can use forms
etc. for user interaction. A module is a container for related
resources. Modules can provide usecases.
Lenya 1.4 has not defined "Resource" yet,
but should relate to one or more of Lenya 1.2's definitions. Software
plug-ins are being defined as "Modules". All graphics should be
"Assets"
I wouldn't introduce a common term for "all graphics". If it's an
image, call it image, if it's a PDF, call it PDF ...
(Why allow static graphics? Let everything be editable, and
improve security so the security granted by requiring file system
access is unnecessary.)
+1
Presentation configuration will be moved
inside Modules. While none of the old definitions of "Resource" are
needed, the word is already used by Lenya, and should be used before
adding a new word.
As I understood it, the term "resource" is rejected by most developers,
because the meaning is too general. But I guess "resource" vs.
"content item" will be a never-ending story unless we do a vote and
all developers commit to the decision.
7. Lenya 1.2 defines "Publication" as "Content and related processing
instructions" where "Content" is defined as "(XML) Documents and
related Assets" where "Assets" is defined as "uploaded files".
People keep suggesting using "Site", "Website", "Book", and other
terms for this concept. General Usage defines "Publication" as "A
specific issue of a public work including textual information". The
output of a Lenya 1.2 Publication is close enough to the General Usage
definition that very few people have been confused by the term. If it
works, do not break it.
+1
8. "Resource" is better than "ContentItem" because it contains fewer words.
Yes, but it bears a greater danger of clashes with other meanings of
the term (see above). My personal priority list is
1. asset
2. resource
3. content item
but they're very close to each other.
===
On 2/7/06, Thorsten Scherler <[EMAIL PROTECTED]> wrote:
What both models of http://wiki.apache.org/lenya/GlossaryStructure have
in common is that "content" is stored in a Publication. Now Andreas is
using frequently the word "structure" in referring to the sitetree or
like solprovider is calling it index of a publication. Seeing it from a
different angle a sitetree or index or structure is nothing else then
the typical table of content (toc) of a (text) book.
1. "TableOfContent" is three words where we have been using one
("Sitetree"). It also implies a single structure.
2. "TOC" is not immediately recognizable by people outside the printed
paper industry.
I agree to these points, but I'd replace "sitetree" with "structure"
or "index".
3. Andreas uses "Structure" to mean the one and only hierarchical
structure of information within a Publication.
Not necessarily, I don't mind having multiple structures per publication,
though the current API draft supports only a single one.
I think more
flexibility would be easy.
4. I use "Index" to refer to an easily configurable internal data
structure used to allow multiple "structures", both flat and
hierarchical. Notice "internal". The only people aware of Indexes
would be:
- Programmers of core that implement the feature.
- Developers of Modules that concern multiple Resources. ("Resource"
being defined as Nodes within Content.)
To clarify, the bulk of understanding "Index" falls to the programmers
of core implementing the feature. The "live" Module is only concerned
with one Resource, so the developer does not need to understand
"Index". The "live" Module aggregates the result of the "menu"
Module. The "menu" Module creates a list of multiple Resources, so
configures a hierarchical Index. The developer of the "menu" Module
only needs to understand that properly using XML to configure an
"Index" allows using the following line to generate XML about multiple
documents:
<map:generate type="sitetree" index="myNewIndex"/>
The SitetreeGenerator does the work; the developer looks at the
resulting XML to see if the Index configuration is correct, then
continues writing the Module (probably adding XSL transformations.)
Indexes would also be used internally to translate between the ID (or
URL) (/section/category/documentid) and the UNID (unique identifier of
the Resource in the flat storage of Content) used to retrieve a
Resource. Again, use of the Index is transparent to everybody except
the core programmers implementing the feature.
That sounds reasonable.
-- 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]
