lenya-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörn Nettingsmeier <pol-ad...@uni-duisburg.de>
Subject Re: [RFC] Terminology
Date Sat, 04 Feb 2006 14:55:28 GMT
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: pol-admin@uni-duisburg.de, Telefon: 0203/379-2736

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org


Mime
View raw message