hi *!
i've been following the terminology discussion with interest. i had been
working on a glossary of terms already, but it got lost when i renamed
it, so bob was probably not aware of it when he started the
CMSTerminology page. anyway, here it is:
http://wiki.apache.org/lenya/Glossary
all definitions on Bob's page have been copied over now, and i suggest
to use this page for further documentation. there are notes about
debated items that hopefully reflect the current state of discussion, if
not, please correct it.
perhaps the CMSTerminology page could be used exclusively for the
cross-reference table that bob has outlined there - it's definitely a
very interesting thing for new users.
-.-
i came across some problems with the current terms when actually trying
to write the docs. it's a good way to find out whether the new terms are
nice or awkward to use:
* "document" as currently defined on
http://wiki.apache.org/lenya/CMSTerminology feels awkward, because it
subtly re-defines a term that everybody thinks they know. (plus it seems
not to reflect the most recent state of discussion.)
i think we should consider that what we now call "document" is basically
a container of language versions and their assets (and possibly their
revision history), and adjust our terminology accordingly.
as a workaround, i have used the term "document id", but it's not much
better. there is also "site tree node", which is somewhat analogous and
my current favourite, unless we allow multiple hierarchies, when it
suddenly becomes orthogonal and plain wrong. :(
maybe it should just be "document container"?
i don't like "content item", because to me it sounds more like a small
snippet, such as a media asset file. and it makes me think of a leaf
node rather than a container. it feels like a stopgap word that i'd hate
to have around forever.
* "language version" does not stand well on its own (version of what?),
it clashes with "version" and totally explodes when you talk about
"language version versions". i suggest to call it a "document", since
that's what most people will intuitively do. in the case where we need
to make i18n issues explicit, we can talk about the "document" (in the
default language) and "document translations" (the other languages). or
maybe even "document versions" belonging to a "document container" (or
better yet, to a "site node").
* let's ditch "version" for old states of a page. instead we can use
"revision" consistently throughout, which is a lot more precise.
* i would prefer "document type" instead of the current "resource type",
because it is already in common usage (everybody knows DTDs). it does
not quite include the processing part, but that trade-off is worth it
given that it will give most people a precise idea of what it is.
we can introduce the additional term "document type handler" for all the
involved xslt and usecases, and summarize it all as a "document type
module".
* we currently have problems with "resource" and "item", because they
are so generic. let's avoid re-defining them for concrete concepts. doc
writers need good and unpolluted terms for abstract concepts sometimes.
looking forward to your comments,
jörn
--
"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]
