On 2/3/06, Andreas Hartmann <[EMAIL PROTECTED]> wrote:
> That's not a vote, but it would be appreciated if you could state
> your opinion. I'd like to emphasize that this discussion is not
> about the API itself, but only about the terms we use. So please
> don't go and complain about the concept of areas or language versions.
> These issues can be discussed later on.
Well, that eliminates some of my ideas. The problem is the technology
follows the terminology.
> ----
> A website in Lenya is called a
> - publication [+1]
> - site
Publication: Collection of data and special processing instructions.
Website: A collection of Publications and other material accessed
through a single Internet domain.
> ----
> The resources of a website can exist at the same time in several
> - areas [+1]
Cannot comment since this terminology hurts the technology.
> ----
> The entirety of plain information (without structuring) is called
> - content [+1]
> - resources
Decision time. Will "Assets" (images and other files) be stored with
the documents?
Historically, "Content" refers only to a collection of "Documents",
and "Resources" referred a collection of "Assets". If "Assets" are
not included, we should keep the term "Content". Either term
("Content" or "Resources") is good for the collection of Documents and
Assets, but changing it to "Resources" may reduce confusion with the
historical definition of "Content".
> ----
> The set of language versions of a piece of information is called
> - content node
> - content item [+1]
> - document
> - resource
I prefer "Document" for an XML Document, because that is what XML and
Lenya1.2 call it.
To refer to something that could be either a Document or an Asset, I
prefer "Resource". "Content Node" uses two words for the same
concept.
"Content Item" sounds like a field or a section of a Document.
> ----
> A specific language version is called
> - content item
> - language version [+1]
> - document
> A version in the history of a language version is called
> - (history) version [+1]
Agreed. "Documents" have "Language Versions" which have "Versions".
"Language Version" sounds fine. "Document Language Node" is more
accurate, but too long.
The nodes which track the historical changes for a specific language
must be "Versions".
> ----
> The structuring information (there may be several of them) are
> - sites
> - structures [+1]
> - navigations
> (maybe we have to make a distinction between "structure" and "navigation")
I think I refer to these concepts as "Navigation Elements" and "Indexes".
Navigation Element: A DIV used by XSL (or the code that creates one)
to provide access to Documents in a structured manner: menus,
breadcrumbs, website maps.
Indexes: Structural information for selecting, sorting, and retrieving
the hierarchical relations of a collection of Documents.
"Sites" is commonly used for "Websites".
"Structures" is fine, but "Indexes" should fit the technology better.
"Navigation" is better/shorter than "Navigation Element", but has the
issue that it is commonly used for the collection of all methods to
navigate a website (Navigation Elements and static links).
> ----
> A node in the structure is called
> - (structure) node [+1]
> - site node
> - navigation item
"Node" is the standard term for an element of a data structure.
---
For me, the following text sounds quite good:
In Lenya, a Website consists of one or more Publications. A
Publication is a collection of Resources (Documents and Assets), and
any special functionality. Documents (and soon Assets) are
maintained by Language, and each edit creates a new Version for
historical documentation and the ability to rollback to an older
Version. Indexes provide selection of Documents for use by various
functionality, including Navigation Elements which provide easy access
to the Documents through the web interface.
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
